[原創(chuàng)文章歡迎轉載，但請保留作者信息]
Justin 于 2009-12-20

大師說了，C++的設計還是有缺陷的：它無法把接口(interface)的設計和實現(implementation)的設計完全劃分開來。比如說在一個類的(接口)聲明當中，總是或多或少的會泄漏一些實現上的細節(jié)，雖然這樣做與接口的設計并沒有太多聯系。
有同學說應該多放些代碼一起炒冷飯，是個好主意，下面是書中的修改版本，大致是一樣的。

class ?AClass {
public :
??? void ?interface_1();
???std:: string ?interface_2();
??? // ..
private :
??? // ?implementation?details?are?leaking?as?below..
???std:: string ?internalData_1;
???BClass?internalData_2;
??? // ..
}

這些實現上的細節(jié)往往需要引用其他頭文件中相關對象的定義(比如說下面的代碼)，從而產生了對這些頭文件的(在編譯時的)依賴。因此每次這些文件中的某個有變化時，依賴它的所有文件都需要重新編譯。

#include? < string >
#include? " BClass.h "
// ..

【注意】這里貌似邏輯不是很順：就算沒有那些私有成員的聲明，接口函數的返回值如果是string或是BClass等類型，不還是一樣需要依賴引用其他頭文件嗎？其實這是兩種不一樣的情況，實現和接口。前面說的實現細節(jié)的泄漏是會導致編譯依賴的，因為編譯器需要了解這些類型對象的大小進而為其分配內存空間；但是接口，比如說函數的返回值或是參數表中的參數，就不需要編譯器去考慮分配內存的問題，因此也就沒有所謂的編譯依賴了。
問題知道了，那么解決辦法呢，大師提出“骨肉分離法”(嗯……其實是我的杜撰@#￥%)：將聲明(declaration)和定義(definition)分開。

呃……下面的比喻，最好吃完飯再繼續(xù)。
如果說接口是一個類的骨架，那么實現就是他的血肉；如果說聲明讓你摸到了骨頭，那么定義應該就是血和肉生長的地方。
根據骨肉分離法，對于一個AClass類，第一步先把血肉(定義/實現)剝離開，只留下骨架。然后找個盒子(新建一個類，比如說AClassImpl)，把血肉放進去。
接下來還有一步，在骨頭盒子里(原AClass類)加一條繩子連著血肉盒子(一個指向AClassImpl的指針)，這樣才不至于讓骨肉真正的分離，只要找到了骨頭盒子，就一定能找到血肉盒子，然后對于這個“可憐”的AClass來說，它的全部“零件”都是完整的，啥也沒丟，但是做到了骨肉分離。

也做到了沒有編譯依賴。
因為對于AClass的用戶來說，他們面對的將是一個沒有定義的類，這個類的后繼改動，只要不涉及接口的改動，都不會導致用戶程序的重新編譯。
看到這里想想工作時看到的代碼，原來前輩也有看過啊……
對比前面的例程，給一個“骨肉分離”了的版本吧：

class ?AClassImpl {
// ..
private :
??? // ?implementation?details?are?moved?here..
???std:: string ?internalData_1;
???BClass?internalData_2;
// ..
}

class ?AClass {
public :
??? void ?interface_1();
???std:: string ?interface_2();
??? // ..
private :
??? // ?there?is?only?a?pointer?to?implementation
???std::tr1::shared_ptr < AClassImpl > ?pImpl;
}

// a?constructor:?instantiations?of?AClass?and?AClassImpl?should?always?be?bound?together.
AClass::AClass( // ..)?:?pImpl(new?AClassImpl( // ..))
{
??? // ..
}

前面的文字是自己的理解，而大師的真言是這樣的：

• 如果可以用指針/引用的話，就不用對象。
• 如果可以做到僅依賴聲明，就不要依賴定義。
• 為定義和聲明分別準備兩個頭文件。這樣一來，用戶就可以很簡單做到上面兩點。

如果覺得骨肉分離太殘忍，大師還有另外一個工具：工廠(factory)。
第二種方法中，抽象類/接口類提供了所有接口的純虛函數形式：會有該類的子類去實現這些接口。與此同時，在抽象類/接口類中還會有一個靜態(tài)(static)的工廠函數(比如create()/produce()/factory()……），這個函數實際上起到了構造函數的作用，它“制造”出子類對象來完成真正的任務，同時返回這個對象的指針(通常是智能指針如shared_ptr)。憑借這個返回的指針就可以進行正常的操作，同時不會有編譯依賴的擔心。一個簡陋的代碼見下：

class ?AClass: public ?AClassFactory {
public :
???AClass()? {}
??? void ?interface_1();
???std:: string ?interface_2();
??? virtual ? ~ AClass();
// ..
}

class ?AClassFactory {
public :
??? virtual ? void ?interface_1()? = ? 0 ;
??? virtual ?std:: string ?interface_2()? = ? 0 ;
??? // ..
??? virtual ? ~ AClassFactory() { /**/ /* .. */ }
??? static ?std::tr1::shared_ptr < AClassFactory > ?Produce( /**/ /* .. */ )
??? {
?????? // this?factory?function?could?be?more?complicated?in?practice..
?????? return ?std::tr1::shared_ptr < AClassFactory > ( new ?AClass);
???}
// ..
}


// AClassFactory?could?be?used?in?this?way..
std::tr1::shared_ptr < AClassFactory > ?pAClassObject;
pAClassObject? = ?AClassFactory::Produce( /**/ /* .. */ );
// pAClassObject->..