在你的開發工作中，你可能需要對于某個類的具體實現做出一個細小的修改。提醒你一下，修改的地方不是類接口，而是實現本身，并且僅僅是私有部分。完成之后，你開始對程序進行重新構建，這時你肯定會認為這一過程將十分短暫，畢竟你只對一個類做出了修改。當你按下“構建”按鈕，或輸入make命令（或者其他什么等價的操作）之后，你驚呆了，然后你臉上便呈現出一個大大的囧字，因為你發現整個世界都重新編譯并重新鏈接了！真是人神共憤！
問題的癥結在于：C++并不擅長區分接口和實現。一個類的定義不僅指定了類接口的內容，而且指明了相當數量的實現細節。請看下面的示例：
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; // 具體實現
};
這里，如果無法訪問Person具體實現所使用的類（即string、Date和Address）定義，那么Person類將不能夠得到編譯。通常這些定義通過#include指令來提供，因此在定義Person類的文件中，你應該能夠找到這樣的內容：
#include <string>
#include "date.h"
#include "address.h"
不幸的是，這樣做使得定義Person的文件對這些頭文件產生了依賴。如果任一個頭文件的內容被修改了，或者這些頭文件所依賴的另外某個頭文件被修改，那么包含Person類的文件就必須重新編譯，有多少個文件包含Person，就要進行多少次編譯操作。這種層疊式的編譯依賴將招致無法估量的災難式后果。
你可能會考慮：為什么C++堅持要將類具體實現的細節放在類定義中呢？假如說，如果我們換一種方式定義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的客戶來說，僅在類接口有改動時，才需要進行重新編譯。
這種想法存在著兩個問題。首先，string不是一個類，它是一個typedef（typedef basic_string<char> string）。于是，針對string的前置聲明就是非法的。實際上恰當的前置聲明要復雜的多，因為它涉及到其他的模板。然而這不是主要問題，因為你本來就不應該嘗試手工聲明標準庫的內容。僅僅使用恰當的#include指令就可以了。標準頭文件一般都不會成為編譯中的瓶頸，尤其是在你的編譯環境允許你利用預編譯的頭文件時更為突出。如果分析標準頭文件對你來說的確是件麻煩事，那么你可能就需要改變你的接口設計，以避免使用那些會帶來多余#include指令的標準類成員。
對所有的類做前置聲明會遇到的第二個（同時也是更顯著的）難題是：在編譯過程中，編譯器需要知道對象的大小。請觀察下面的代碼：
int main()
{
int x; // 定義一個int
Person p( 參數 ); // 定義一個Person
...
}
當編譯器看到了x的定義時，它們就知道該為其分配足夠的內存空間（通常位于棧中）以保存一個int值。這里沒有問題。每一種編譯器都知道int的大小。當編譯器看到p的定義時，他們知道該為其分配足夠的空間以容納一個Person，但是他們又如何得知Person對象的大小呢？得到這一信息的唯一途徑就是通過類定義，但是如果省略類定義具體實現細節是合法的，那么編譯器又如何得知需要分配多大空間呢？
同樣的問題不會在Smalltalk和Java中出現，因為在這些語言中，每當定義一個對象時，編譯器僅僅分配指向該對象指針大小的空間。也就是說，在這些語言中，上面的代碼將做如下的處理：
int main()
{
int x; // 定義一個int
Person *p; // 定義一個Person
...
}
當然，這段代碼在C++中是合法的，于是你可以自己通過“將對象實現隱藏在指針之后”來玩轉前置聲明。對于Person而言，實現方法之一就是將其分別放在兩個類中，一個只提供接口，另一個存放接口對應的具體實現。暫且將具體實現類命名為PersonImpl，Person類的定義應該是這樣的：
#include <string> // 標準庫成員，不允許對其進行前置聲明
#include <memory> // 為使用tr1::shared_ptr; 稍后介紹
class PersonImpl; // Person實現類的前置聲明
class Date; // Person接口中使用的類的前置聲明
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;
}; // 關于std::tr1::shared_ptr的更多信息
// 參見條目13
在這里，主要的類（Person）僅僅包括一個數據成員——一個指向其實現類（PersonImpl）的指針（這里是一個tr1::shared_ptr，參見條目13）。我們通常將這樣的設計稱為pimpl慣用法（指向實現的指針）。在這樣的類中，指針名通常為pImpl，就像上面代碼中一樣。
通過這樣的設計，Person的客戶將會與日期、地址和人這些具體信息隔離開。你可以隨時修改這些類的具體實現，但是Person的客戶不需要重新編譯。另外，由于客戶無法得知Person的具體實現細節，他們就不容易編寫出依賴于這些細節的代碼。這樣做真正起到了分離接口和實現的目的。
這項分離工作的關鍵所在，就是用聲明的依賴來取代定義的依賴。這就是最小化編譯依賴的核心所在：只要可行，就要將頭文件設計成自給自足的，如果不可行，那么就依賴于其他文件中的聲明語句，而不是定義。其他一切事情都應遵從這一基本策略。于是有：
l 只要使用對象的引用或指針可行時，就不要使用對象。只要簡單地通過類型聲明，你就可以定義出類型的引用和指針。反觀定義類型對象的情形，你就必須要進行類型定義了。
l 只要可行，就用類聲明依賴的方式取代類定義依賴。請注意，如果你需要聲明一個函數，該函數會使用某個類，那么在任何情況下類的定義都不是必須的。即使這個函數以傳值方式傳遞或返回這個類的對象：
class Date; // 類聲明
Date today(); // 這樣是可行的
void clearAppointments(Date d); // 沒有必要對Date類做出定義
當然，傳值方式在通常情況下都不會是優秀的方案（參見條目20），但是如果你出于某種原因使用了傳值方式時，此時必將引入不必要的編譯依賴，你依然難擇其咎。
即使不定義Date的具體實現，today和clearAppointments依然可以正確聲明，C++的這一能力可能會讓你感到吃驚，但是實際上這一行為又沒有想象中那么古怪。如果代碼中任意一處調用了這些函數，那么在這次調用前的某處必須要對Date進行定義。此時你又有了新的疑問：為什么我們要聲明沒有人調用的函數呢,這不是多此一舉嗎？這一疑問的答案很簡單：這種函數并不是沒有人調用，而是不是所有人都會去調用。假設你的庫中包含許多函數聲明，這并不意味著每一位客戶都會使用到所有的函數。上文的做法中，提供類定義的職責將從頭文件中的函數聲明轉向客戶端文件中包含的函數調用，通過這一過程，你就排除了手工造成的客戶端類定義依賴，這些依賴實際上是多余的。
l 為聲明和定義分別提供頭文件。為了進一步貫徹上文中的思路，頭文件必須要一分為二：一個存放聲明，另一個存放定義。當然這些文件必須保持相互協調。如果某處的一個聲明被修改了，那么相應的定義處就必須做出相應的修改。于是，庫的客戶就應該始終使用#include指令來包含一個聲明頭文件，而不是自己進行前置聲明，庫的作者應提供兩個頭文件。比如說，在Date的客戶期望聲明today和clearAppointments時，就應該無需向上文中那樣，對Date進行前置聲明。更好的方案是用#include指令來引入恰當的聲明頭文件：
#include "datefwd.h" // 包含Date類聲明(而不是定義)的頭文件
Date today(); // 同上
void clearAppointments(Date d);
頭文件“datefwd.h”中僅包含聲明，這一名字基于C++標準庫中的<iosfwd>（參見條目54）。<iosfwd>包含著IO流組件的聲明，這些組件相應的定義分別存放在不同的幾個頭文件中，包括：<sstream>、<streambuf>、<fstream>以及<iostream>。
從另一個角度來講，使用<iosfwd>作示例還有一定的示范效應，因為它告訴我們本節中的建議不僅對非模板的類有效，而且對模板同樣適用。盡管在條目30中分析過，在許多構建環境中，模板定義通常保存在頭文件中，一些構建環境中還是允許將模板定義放置在非頭文件的代碼文件里，因此提供為模板提供僅包含聲明的頭文件并不是沒有意義的。<iosfwd>就是這樣一個頭文件。
C++提供了export關鍵字，它用于分離模板聲明和模板定義。但是遺憾的是，支持export的編譯器是十分有限的，現實中export的應用更是寥寥無幾。因此在高效C++編程中，export究竟扮演什么角色，討論這個問題還為時尚早。
諸如Person此類使用pimpl慣用法的類通常稱為句柄類。為了避免你對這樣的類如何工作產生疑問，一個途徑就是將類中所有的函數調用放在相關的具體實現類之前，并且讓這些具體實現類去做真實的工作。請看下面的示例，其中演示了Person的成員函數應該如何實現：
#include "Person.h" // 我們將編寫Person類的具體實現，
// 因此此處必須包含類定義。
#include "PersonImpl.h" // 同時，此處必須包含PersonImpl的類定義，
// 否則我們將不能調用它的成員函數；請注意，
// PersonImpl擁有與Person完全一致的成員
// 函數 - 也就是說，它們的接口是一致的。
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的構造函數是如何調用PersonImpl的構造函數的（通過使用new - 參見條目16），以及Person::name是如何調用PersonImpl::name的。這兩點很重要。將Person定制為一個句柄類并不會改變它所做的事情，而是僅僅改變它做事情的方式。
除了句柄類的方法，我們還可以采用一種稱為“接口類”的方法來將Person定制為特種的抽象基類。這種類的目的就是為派生類指定一個接口（參見條目34）。于是，通常情況下它沒有數據成員，沒有構造函數，但是擁有一個虛析構函數（參見條目7），以及一組指定接口用的純虛函數。
接口類與Java和.NET中的接口一脈相承，但是C++并沒有像Java和.NET中那樣對接口做出非常嚴格的限定。比如說，無論是Java還是.NET都不允許接口中出現數據成員或者函數實現，但是C++對這些都沒有做出限定。C++擁有更強靈活性是有實用價值的。就像條目36中所解釋的那樣，由于非虛函數的具體實現對于同一層次中所有的類都應該保持一致，因此不妨將這些函數實現放置在聲明它們的接口類中，這樣做是有意義的。
Person的接口類可以是這樣的：
class Person {
public:
virtual ~Person();
virtual std::string name() const = 0;
virtual std::string birthDate() const = 0;
virtual std::string address() const = 0;
...
};
這個類的客戶必須要基于Person的指針和引用來編寫程序，因為實例化一個包含純虛函數的類是不可能的。（然而，實例化一個繼承自Person的類卻是可行的——參見下文。）就像句柄類的客戶一樣，接口類客戶除非遇到接口類的接口有改動的情況，其他任何情況都不需要對代碼進行重新編譯。
接口類的客戶必須有一個創建新對象的手段。通常情況下，它們可以通過調用真正被實例化的派生類中的一個函數來實現，這個函數扮演的角色就是派生類的構造函數。這樣的函數通常被稱作工廠函數（參見條目13）或者虛構造函數。這種函數返回一個指向動態分配對象的指針（最好是智能指針——參見條目18），這些動態分配的對象支持接口類的接口。這樣的函數通常位于接口類中，并且聲明為static的：
class Person {
public:
...
static std::tr1::shared_ptr<Person> // 返回一個tr1::shared_ptr，
create(const std::string& name, // 它指向一個Person對象，這個
const Date& birthday, // Person對象由給定的參數初始化，
const Address& addr); // 為什么返回智能指針參見條目18
...
};
客戶這樣使用：
std::string name;
Date dateOfBirth;
Address address;
...
// 創建一個支持Person接口的對象
std::tr1::shared_ptr<Person>
pp(Person::create(name, dateOfBirth, address));
...
std::cout << pp->name() // 通過Person的接口使用這一對象
<< " was born on "
<< pp->birthDate()
<< " and now lives at "
<< pp->address();
... // 當程序執行到pp的作用域之外時，
// 這一對象將被自動刪除——參見條目13
當然，與此同時，必須要對支持某一接口類的接口的具體類做出定義，并且必須有真實的構造函數得到調用。比如說，有一個具體的派生類RealPerson使用了接口類Person，這一派生類應為其繼承而來的虛函數提供具體實現：
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還可以以一個更加貼近現實的方法來實現，它應能夠創建不同種類的派生類對象，創建的過程基于某些相關信息，例如：新加入的函數的參數值、從一個文件或數據庫中得到讀到的數值，環境變量，等等。
RealPerson向我們展示了實現接口類的兩種最通用的實現機制之一：它的接口規范繼承自接口類（Person），然后實現接口中的函數。第二種實現接口類的方法牽扯到多重繼承，那是條目40中探索的主題。
句柄類和接口類將接口從實現中分離開來，因此降低了文件間的編譯依賴。如果你喜歡吹毛求疵，那么你一定在等待我來添加一條注釋。“這么多變魔術般古怪的事情會帶來多大開銷？”這個問題的答案就是計算機科學中極為普遍的一個議題：你的程序在運行時更慢了一步，另外，每個對象所占的空間更大了一點。
使用句柄類的情況下，成員函數必須通過實現指針來取得對象的數據。這樣無形中增加了每次訪問時迂回的層數。同時，為保證每個對象都擁有足夠的內存空間，你必須增大實現指針所指向的區域的內存空間。最后，你必須要對實現指針進行初始化（在句柄類的構造函數中），以便于將其指向一個動態分配的實現對象，這樣做將會招致動態內存分配（以及由此產生的釋放）所帶來的固有的開銷，也有可能遭遇bad_alloc（內存不足）異常。
由于對于接口類來說每次函數調用都是虛擬的，因此你在每調用一次函數的過程中你就會為其付出一次間接跳轉的代價（參見條目7）。同時，派生自接口類的對象必須包含一個虛函數表指針（依然參見條目7）。這一指針也可能會加大保存一個對象所需要的空間，這取決于接口類是否是該對象中虛函數的唯一來源。
最后，無論是句柄類還是接口類，都不適合于過多使用內聯。條目30中解釋了為什么一般情況下要將內聯的函數體放置在頭文件中，然而句柄和接口類都是特別設計用來隱藏諸如函數體等具體實現內容的。
然而，對于句柄類和接口類來說，僅僅由于它們會帶來一些額外的開銷就遠離它們，也是一個嚴重的錯誤。你并不會因為虛函數存在缺點放棄使用它，不是嗎？（如果你真的想放棄，那么你可能看錯書了。）你應該以一個進化演進的方式來使用這些技術。在開發過程中，嘗試使用句柄類和接口類來減少改動具體實現時為客戶帶來的影響。在生產環境中，如果應用這些技術導致程序的速度和/或大小的變動足夠顯著，從而沖淡了不同的類之間所增加關系度的影響，應適時使用具體的類來取代句柄類和接口類。
時刻牢記
l 最小化編譯依賴的基本理念就是使用聲明依賴代替定義依賴。基于這一理念有兩種實現方式，它們是：句柄類和接口類。
l 庫的頭文件必須以完整、并且僅存在聲明的形式出現。無論是否涉及模板。