条款 31：将文件间的编译依存关系降至最低
《Effective C++ 中文版 第三版》读书笔记
** 条款 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 定义式可以合法的不列出实现细目，编译器如何知道该分配多少空间？
此问题在 smalltalk，java 等语言上并不存在，因为当我们以那种语言定义对象时，编译器只分配足够空间给一个指针（用于指向该对象）使用。就是说它们将上述代码视同这样子：
int main()
{
int x;
Person* p;
}
这当然也是合法的 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 的办法是，令 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 = 0;
virtual std::string birthday() const = 0;
virtual std::string address() const = 0;
...
};
这个 class 的客户必须以 Person 的 pointers 和 reference 来撰写应用程序，不能针对 “内含 pure virtual 函数” 的 Person classes 具现出实体。除非 Interface class 的接口被修改否则其客户不需要重新编译。
Interface class 的客户必须有办法为这种 class 创建新对象。它们通常调用一个特殊函数，此函数扮演一个 “真正将被具现化” 的那个 derived class 的构造函数角色。通常称为工厂 factory 函数或 virtual 构造函数。它们返回指针(或者更为可取的智能指针)，指向动态分配所得对象，而该对象支持 interface class 的接口。这样的函数又往往在 interface class 内被声明为 static：
class Person{
public:
...
static std::tr1::shared_ptr<Person>
create(const std::string& name, const Date& birthday, const Address& addr);
};
客户可能会这样使用它们：
std::string name;
Date dateBirth;
Address address;
std::tr1::shared_ptr<Person> pp(Person::create(name, dateBirth, address));
...
std::cout << pp->name()
<< "was born on "
<< PP->birthDate()
<< " and now lives at "
<< pp->address();
...
当然支持 interface class 接口的那个具象类（concrete classes）必须被定义出来，而真正的构造函数必须被调用。
假设有个 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> Person::create(const std::string& name, const Date& birthday, const Address& addr)
{
return std::tr1::shared_ptr<Person>(new RealPerson(name, birthday, addr));
}
一个更现实的 Person::create 实现代码会创建不同类型的 derived class 对象，取决于诸如额外参数值、独自文件或数据库的数据、环境变量等等。
RealPerson 示范实现了 Interface class 的两个最常见机制之一：从 interface class 继承接口规格，然后实现出接口所覆盖的函数。
handle classes 和 interface classes 解除了接口和实现之间的耦合关系，从而降低文件间的编译依存性。
handle classed 身上，成员函数必须通过 implementation pointer 取得对象数据。那会为每一次访问增加一层间接性。每个对象消耗的内存必须增加一个 implementation pointer 的大小。 implementation pointer 必须初始化指向一个动态分配的 implementation object，所以还得蒙受因动态内存分配儿带来的额外开销。
Interface classes，由于每个函数都是 virtual，必须为每次函数调用付出一个间接跳跃。此外 Interface class 派生的对象必须内含一个 vptr（virtual table pointer）。
在程序开发过程中使用 handle class 和 interface class 以求实现码有所改变时对其客户带来最小冲击。
而当他们导致速度和/或大小差异过于重大以至于 class 之间的耦合相形之下不成为关键时，就以具象类（concrete class）替换 handle class 和 interface class。
** 请记住： **
- 支持 “编译依存最小化” 的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是 Handle class 和 Interface class。
- 程序库头文件应该以 “完全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否涉及 templates 都适用。
