Effective C++读书笔记：条款31

31将文件间的编译依存关系降至最低：

假设你对 C++ 程序的某个 class 实现文件做了些轻微改变，修改的不是接口，而是实现，而且只改 private 成分。

然后重新建置这个程序，并预计只花数秒就好，当按下 “Build” 或键入 make，会大吃一惊，因为你意识到整个世界都被重新编译和链接了！

问题是在 C++ 并没有把 “将接口从实现中分离” 做得很好。class 的定义式不只详细叙述了 class 接口，还包括十足的实现细目：

class Person{ 
public: 
    Person(const std::string& name, const Date& birthday, const Address& addr); 
    std::string name() const; 
    std::string birthDate() const; 
    std::string address() const; 
    ... 
private: 
    std::string theName;        //实现细目 
    Date theBirthDate;          //实现细目 
    Address theAddress;         //实现细目 
};

这个 class Person 无法通过编译，Person 定义文件的最上方可能存在这样的东西：

#include <string> 
#include "date.h" 
#include "address.h"

这样一来，便在 Person 定义文件和其含入文件之间形成了一种编译依存关系（compilation dependency）。如果这些头文件中有任何一个被改变，或这些文件所依赖的其他头文件有任何改变，那么每个含入 Person class 的文件就得重新编译，任何使用 Person class 的文件也必须重新编译。这样的的连串编译依存关系（cascading compilation dependencies）会对许多项目造成难以形容的灾难。

为什么 C++ 坚持将 class 的实现细目置于 class 定义式中？为什么不这样定义 Person，将实现细目分开叙述：

namespace std { class string;} // 前置声明（不正确） 
class Date;// 前置声明 
class Address;// 前置声明 

class Person{ 
public: 
    Person(const std::string& name, const Date& birthday, const Address& addr); 
    std::string name() const; 
    std::string birthDate() const; 
    std::string address() const; 
    ... 
};

如果这样，Person 的客户就只有在 Person 接口被修改时才重新编译。

两个问题：第一，string 不是个 class，它是个 typedef。因此 string 前置声明并不正确，而且你本来就不应该尝试手工声明一部分标准程序库。你应该仅仅使用适当的 #includes 完成目的。标准头文件不太可能成为编译瓶颈，

第二，编译器必须在编译期间知道对象的大小：

int main() 
{ 
    int x; 
    Person p(params); 
}

编译器知道必须分配足够空间放置一个 Person，但是他必须知道一个 Person 对象多大，获得这一信息的唯一办法是询问 class 定义式。然而，如果 class 定义式可以合法的不列出实现细目，编译器如何知道该分配多少空间？

这当然也是合法的 C++ 代码，所以你可以玩玩 “将对象实现细目隐藏在一个指针背后” 的游戏。可以把 Person 分割为两个 classes，一个提供接口，另一个负责实现接口。负责实现的那个所谓的 implementation class 取名为 PersonImpl，Person 将定义如下：

#include <string> 
#include <memory> 
class PersonImpl; 
class Date; 
class Address; 

class Person{ 
public: 
    Person(const std::string& name, const Date& birthday, const Address& addr); 
    std::string name()const; 
    std::string birthDate() const; 
    std::string address()const; 
    ... 

private: 
    std::tr1::shared_ptr<PersonImpl> pImpl; // 指向实现物的指针 
};

这里，Person 只内含一个指针成员，指向其实现类（PersonImpl）。这个设计常被称为 pimpl idiom（pimpl 是 “pointer to implementation” 的缩写）。

这样，Person 的客户就完全与 Date，Address 以及 Person 的实现细目分离了。那些 classes 的任何实现修改都不需要 Person 客户端重新编译。

这个分离的关键在于以 “声明的依存性” 替换 “定义的依存性”，那正是编译依存性最小化的本质：让头文件尽可能自我满足，万一做不到，则让它与其他文件内的声明式（而非定义式）相依。其他每件事都源自于这个简单的涉及策略。

如果用 object reference 或 object pointer 可以完成任务，就不要用 objects。

可以只靠声明式定义出指向该类型的 pointer 和 reference；但如果定义某类型的 objects，就需要用到该类型的定义式。

如果能够，尽量以 class 声明式替换 class 定义式。

当你声明一个函数而它用到某个 class 时，你并不需要该 class 的定义式，纵使函数以 by value 方式传递该类型的参数（或返回值）亦然：

class Date; // class 声明式 
Date today(); 
void clearAppiontments(Date d);

声明 today 函数和 clearAppointments 函数无需定义 Date，但是一旦有任何人调用那些函数，调用之前 Date 定义式一定得先曝光才行。如果能够将 “提供 class 定义式”（通过 #include 完成）的义务从 “函数声明所在” 之头文件移转到 “内含函数调用” 之客户文件，便可将 “并非真正必要之类型定义” 与客户端之间的编译依存性去除掉。

为声明式和定义式提供不同的头文件。

因此程序库客户应该总是 #inlcude 一个声明文件而非前置声明若干函数，

#include "datefwd,h" // 这个头文件内声明 class Date 
Date today(); 
void clearAppointments(Date d);

只含声明式的那个头文件名为 “datefwd.h”，像标准程序库的头文件 “<iosfwd>”。他分外彰显 “本条款适用于 templates 也适用于 non-templates”。许多建置环境中 template 定义式同常被置于头文件中，但也有某些建置环境允许 tamplates 定义式放在 “非头文件中”，这样就可以将 “只含声明式” 的头文件提供给 templates。

这种使用 pimpl idiom 的 classes，往往被称为 Handle classes。

这种 classes 的办法之一就是将他们的所有函数转交给相应的实现类（implementation classes）并由后者完成实际工作。

#include "Person.h" 
#include "PersonImpl.h" 

Person::Person(const std::string& name, const Date& birthday, const Address& addr) 
    : pImpl(new PersonImpl(name, birthday, addr)) 
{} 

std::string Person::name() const 
{ 
    return pImpl->name(); 
}

请记住:

支持 “编译依存最小化” 的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是 Handle class 和 Interface class。
程序库头文件应该以 “完全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否涉及 templates 都适用。

数据结构之二叉搜索树

Effective C+读书笔记：条款32

Comments NOTHING

取消回复