[Effective C++ --031]将文件间的编译依存关系降至最低

引言：编译时间成本

在项目中我们都会碰到修改既存类的情况：某个class实现文件做了些轻微改变，修改的不是接口，而是实现，而且只改private成分。

重新build这个程序，并预计只花数秒就好，当按下“Build”，结果整个世界都被重新编译和链接了！

问题是在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;         //实现细节
 };

在这个类上方，应该还存在着：

 #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;             // 定义一个int
     Person p(params);  // 定义一个Person
 }

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

针对这个问题，smalltalk，java实现了一个类似下面代码的逻辑：

 int main()
 {
     int x;             // 定义一个int
     Person p(params);  // 定义一个指针指向Person
 }

这样的功能在C++被叫做PIMPL，即：

 #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的客户就完全与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);

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

这种使用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的办法是，令Person称为一种特殊的abstract base class（抽象基类）称为Interface classes。这种class的目的是详细一一描述derived classes的接口，因此它通常不带成员变量，也没有构造函数，只有一个virtual析构函数以及一组pure virtual函数，又来叙述整个接口。

一个针对Person而写的Interface class或许看起来像这样：

 class Person{
 public:
     virtual ~Person();
     virtual std::string name() const = ;
     virtual std::string birthday() const = ;
     virtual std::string address() const = ;
     ...
 };

◆总结

1.支持“编译依存最小化”的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classes和Interface classes。

2.程序库头文件应该以“安全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否涉及templates都适用。