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

 假设你对C++程序的某个class实现文件做了些轻微修改，假如只改了private部分，然后，重新建置这个程序，你以为只需花数秒，但你会发现，整个世界都被重新编译和连接了。

上述问题出现在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 assress() const;
    //...
private:
    std::string theName;//实现细目
    Date theBirthDate;//实现细目
    Address theAddress;//实现细目
};

若编译器没有取得class Person实现代码所用到的class string，Date和Address的定义式，这里的Person就无法通过编译。

这样的定义式通常由#include指示符提供，所以Person定义文件的最上方很可能存在这样的东西：

#include 
#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 assress() const;
    //...
};

若可以这么做，Person的客户就只需要在Person接口被修改过时才重新编译。

这个想法存在两个问题：

1.string不是个class，他是个typedef（定义为basic_string）。因此，上述针对string而做的前置声明并不正确；正确的前置声明比较复杂，因为涉及额外的template。然而这不要紧，因为你本来就不该尝试手工声明一部分标准程序库。你应该仅仅使用适当的#include完成目的。

2.关于”前置声明每一件东西“的第二个困难是，编译器必须在编译期间知道对象的大小。

例如：

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

当编译器看到x的定义式，它知道必须分配多少内存（通常位于stack内）才够有一个int。这没有问题，因为每一个编译器都知道一个int有多大。

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

我们的一个解决方法是：把Person分割为两个class，一个只提供接口，另一个负责实现该接口。若负责实现的那个所谓implementation class（实现类）取名为PersonImpl，则Person的定义如下：

#include //标准程序库组件不该被前置声明
#include //此乃为了tr1::shared_ptr而含入
class PersonImpl;//Person实现类的前置声明
class Date;//Person接口用到的class的前置声明
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 assress() const;
    //...
private:
    std::tr1::shared_ptr pImpl;//指针，指向实现物
};

上述代码中，main class（Person）只内含一个指针成员（这里使用tr1::shared_ptr）指向其实现类（PersonImpl）。这般设计常被称为pimpl idiom（pimpl是"pointer to implementation"的缩写）。这种class内的指针名称往往就是pImpl，就像上述代码那样。

这样设计，Person的客户就完全与Date，Adress以及Person的实现细目分离了。那些class的任何实现修改都不需要Person客户端重新编译。此外，由于客户无法看到Person的实现细目，也就不可能写出什么”取决于那些细目“的代码。

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

 1.若使用object reference或object pointer可以完成任务，就不要使用object。

你可以只靠一个类型声明式就定义出指向该类型的reference和pointer；但若定义某类型的object，就需要用到该类型的定义式。

2.如果可以，尽量以class声明式替换class定义式。

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

class Date；//class声明式
Date today();//没问题，这里不需要Date的定义式
void clearAppointments(Date d);

 声明roday函数和clearAppointments函数而无需定义Date，这种能力可能会令你惊讶，但它并不是真的那么神奇。一旦任何人调用那些函数，调用之前Date定义式一定得先曝光才行。

那么或许你会疑惑，何必费心声明一个没人调用的函数呢？注意，并非没人使用，而是并非每个人都调用。

假设你有一个函数库内含数百个函数声明，不太可能每个用户叫便每一个函数。若能够将“提供class定义式”（通过#include完成）的义务从“函数声明所在”的头文件转移到“内含函数调用”的客户文件，便可将“并非真正必要的类型定义”与客户端之间的编译依存性去除掉。

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

为了严守上述准则，需要两个头文件，  一个用于声明式，一个用于定义式。当然，这些文件必须保持一致性，若有个声明式被改变了，两个文件都得改变。因此程序库客户应该总是#include一个声明文件而非前置声明若干函数，程序库作者也应该提供这两个头文件。

例如，Date的客户若希望声明today和clearAppointments，他们不该像先前那样以手工方式前置声明Date，而是应该#include适当的、内含声明式的头文件：

#include "datefwd.h"//这个头文件内声明（但未定义）class Date
Date today();//同前
void clearAppointments(Date d);

像Person这样使用pimpl idiom的class，往往被称为Handle class。也许你会纳闷，这样的class如何真正做点事情。

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

例如，下面是Person的两个成员函数的实现：

#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();
}

注意，Person构造函数以new调用PersonImpl构造函数，以及Person::name函数内调用PersonImpl::name。这是重要的，让Person变成一个Handle class并不会改变它做的事，只会改变它做事的方法。

另一个制作Handle class的办法是，令Person成为一种特殊的abstract base class（抽象基类）,称为interface class。这种class的目的是详细一一描述derived class的接口，因此它通常不带成员变量，也没有构造函数，只有一个virtual析构函数以及一组pure virtual函数，用来叙述整个接口。

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

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

这个class的客户必须以Person的pointer和reference来撰写应用程序，因为它不可能针对“内含pure virtual函数”的Person class具现出实体。就像Handle class的客户一样，除非Interface class的接口被修改否则其客户不需重新编译。

Interface class的客户必须有办法为这种class创建新对象。他们通常调用一个特殊函数，此函数扮演“真正将被具现化”的那个derived class的构造函数角色。这样的函数通常称为factory（工厂）函数或virtual构造函数。它们返回指针（或更为可取的智能指针），指向动态分配所得对象，而该对象支持Interface class的接口。这样的函数往往在Interface class内被声明为static：

class Person {
public:
    //...
    static std::tr1::shared_ptr 
        create(const std::string& name, const Date& birthday, const Address& addr);
    //返回一个tr1::shared_ptr，指向一个新的Person，并以给定的参数初始化
    //...
};

客户会这样使用它们：

std::string name;
Date dateOfBirth;
Address address;
//...
//创建一个对象，支持Person接口
std::tr1::shared_ptr pp(Person::create(name, dateOfBirth, address));
//...
//通过Person的接口使用这个对象
cout << pp->name() << "  was born on " 
     << pp->birthDate() << " and now lives at " 
     << pp->address();
//...
//当pp离开作用域，对象会被自动删除

当然，支持Interface class接口的那个具象类（concrete class）必须被定义出来，而且真正的构造函数必须被调用。一切都在virtual构造函数实现码所在的文件内秘密发生。假设Interface class Person有个具象的derived class RealPerson，后者提供继承而来的virtual函数的实现：

class RealPerson :public Person {
public:
    RealPerson(const std::string& name,const Date& birthday, const Address& addr)
        :theName(name),theBirthDate(birthday),theAddress(addr){}
    virtual ~RealPerson() {}
    std::string name() const;
    std::string birthDate() const;
    std::string address() const;
private:
    std::string theName;
    Date theBirthDate;
    Address theAddress;
};

有了RealPerson之后，写出Person::create就不稀奇了：

std::tr1::shared_ptr 
Person::create(const std::string& name, const Date& birthday, const Address& addr)
{
    return std::tr1::shared_ptr(new RealPerson(name, birthday, addr));
}

一个更现实的Person::create实现代码会创建不同类型的derived class对象，取决于诸如额外参数值、读自文件或数据库的数据、环境变量等等。

RealPerson示范实现Interface class的两个最常见机制之一：从Interface class(Person）继承接口规格，然后实现出接口所覆盖的函数。第二个实现法涉及多重继承。

Handle class和Interface class解除了接口和实现之间的耦合关系，从而降低文件间的编译依存性（compilation dependencies）。

但这是有代价的，它使你在运行期丧失若干速度，又让你为每个对象超额付出若干内存。

在Handle class身上，成员函数必须通过implementation pointer取得对象数据。那会为每一次访问增加一层间接性。而每一个对象消耗的内存数量必须增加implementation pointer的大小。最后，implementation pointer必须初始化（在Handle class构造函数内），指向一个动态分配得来的implementation object，所以你将蒙受因动态内存分配（及其后的释放动作）而来的额外开销，以及遭遇bad_alloc异常（内存不足）的可能性。

至于Interface class，由于每个函数都是virtual，所以你必须为每次函数调用付出一个间接跳跃（indirect jump）成本。此外Interface class派生的对象必须内含一个vptr（virtual table pointer），这个指针可能会增加存放对象所需的内存数量——实际取决于这个对象除了Interface class之外是否还有其他virtual函数来源。

最后，不论Handle class或Interface class，一旦脱离inline函数都无法有太大作为。

总结

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

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