Basic Sample Senario :

Client 需要一種組件提供一種 FastString類， 此類具有 int length() 方法

解決方案：

靜態(tài)鏈接 ： 組件廠商將源代碼交給 client ，客戶將組件代碼與client 代碼編譯連接運行。 如果組件代碼需要fix bug or update ，則client 端代碼需要重新編譯連接。 而且client軟件的不同實例使用各自的組件內(nèi)存對象。

動態(tài)鏈接 ： 組件廠商使用DLL形式發(fā)放組件，此時不同的client實例可以共享組件在內(nèi)存中的代碼段。

DLL的問題：1.導出名稱的問題 ： 不同的compiler可以使用不同的mangle name 用來區(qū)分 c++的函數(shù)，那么使用不同的compiler的client和組件無法鏈接 （可以使用extern “C”解決全局函數(shù)名的問題，使用 .DEF文件解決導出成員函數(shù)的問題）

                   2.升級的問題 ：如果組件最初定義為

class FastString
{
    char* m_psz;
public:
    FastString(const char* psz){strcpy(m_psz, psz);}
};

                                          而后廠商更改了組件的實現(xiàn)

class FastString
{
int newmember;
char* psz;
public:

FastString(const char* psz){strcpy(m_psz, psz);}

}

原來FastString對象大小為4字節(jié)，現(xiàn)在變?yōu)?字節(jié)，但是client端按照4字節(jié)分配對象， dll卻要向后面的4個字節(jié)存入一個指針，行為不可預(yù)料！

解決這一問題的一種方法便是每次發(fā)布便更改dll的名字，即1.0, 2.0, x.0 等等。但這樣比較弱啊！！

這種問題根本原因是啥呢？

class 的關(guān)鍵在于封裝了其中的實現(xiàn)細節(jié)，即用戶知道類提供了哪些服務(wù)（ public方法）就行了，不需要管類的內(nèi)部到底使用了哪些成員變量。這樣一來，只要接口沒變（類提供功能），user就可以安心的使用任意版本的實現(xiàn)了。C++怎么不行呢？C++告訴用戶接口的同時，也告訴了用戶類的實現(xiàn)(對象布局)。比如類對象有多大啊，每個成員的偏移啊(具體可以看Inside c++ object model)。知道了這些，客戶端使用接口的代碼就和DLL中的具體實現(xiàn)緊密的耦合起來了，杯具 啊~

咋辦呢？ 只要不讓client直接創(chuàng)建FastString就行了，這樣client的代碼就不會受到FastString實現(xiàn)變化的影響了。給FastString加一個Wrapper類，內(nèi)部嵌套一個FastString，所有對FastString的調(diào)用都foward給內(nèi)部的FastString member, 創(chuàng)建FastString 的任務(wù)在dll方面完成，client只知道Wrapper大小為4個字節(jié)--指向FastString的指針。這樣問題解決了，但是太麻煩了，所有的接口都要包一層!! 而且多了一層調(diào)用!

還有啥辦法么？ 為了保證c++接口類實現(xiàn)二進制級別的兼容只能使用編譯器無關(guān)的特性：1.假設(shè)復合類型表現(xiàn)形式相同(struct) 2. 傳參順序相同，可以使用指示符指定3.虛函數(shù)調(diào)用機制相同，即基于 vtbl 和 vptr. 基于這些假設(shè)，我們創(chuàng)建的c++接口類所有函數(shù)設(shè)置為虛函數(shù)，那么不同compiler將為客戶端方法調(diào)用產(chǎn)生相同的機器代碼。定義了接口，便規(guī)定了所有繼承于他的類的內(nèi)存結(jié)構(gòu)一定與它兼容。但此時不能告訴用戶類的定義，否則重回上面的老路上了。怎么辦，只有接口客戶無法創(chuàng)建類的定義，只有export一個創(chuàng)建類對象的函數(shù)客戶了。  同上面的wrapper一樣，創(chuàng)建類的操作僅僅在dll內(nèi)部調(diào)用，這意味著實際建造類對象大小和布局的代碼與編譯實現(xiàn)類的方法的代碼使用同樣的編譯器創(chuàng)建 （即ctor和call ctor的代碼由同一編譯器同時編譯）。由于虛析構(gòu)函數(shù)在vtbl的位置與compiler相關(guān)，所以不能把它設(shè)置為虛函數(shù)，只有顯示增加一個Delete函數(shù)完成析構(gòu)工作。

OK，當前我們得到的DLL中只有創(chuàng)建類對象的函數(shù)需要用extern “C”export 給客戶，其他的接口中的虛函數(shù)是通過虛表訪問的，無需靠符號名字鏈接。

進一步的，如果我們要給接口增加一個功能呢？ 如果直接在現(xiàn)有接口中方法聲明后加入新的方法，那么此方法會出現(xiàn)在vtbl的最后一欄，舊的client不會調(diào)用新方法，但是如果新的client訪問老的對象呢? 不幸的事情發(fā)生了！ 這樣做的問題在于，修改公開的接口就打破了對象的封裝性。

那么增加接口功能只能通過設(shè)計一個接口繼承另一個接口，或者讓類繼承多個接口來實現(xiàn)了。客戶可以在運行時通過RTTI來詢問對象，支持這個功能不，親？然而 ，RTTI也是一個compiler相關(guān)的東東，好吧，我們讓每個類自己實現(xiàn)RTTI，也就是實現(xiàn)一個dynamic_cast 方法， 用來將自己cast成為自己實現(xiàn)的接口，如果不支持則返回 0 。

例如：

void* CFastString::Dynamic_Cast(const char* pszTypename)
{
void * pRev;
if(strcmp(pszTypename, "IFastString") == 0)
{
pRev = static_cast<IFastString*>(this);
}
else if(strcmp(pszTypename , "IOut") == 0)
{
pRev = static_cast<IOut*>(this);
}
else if(strcmp(pszTypename , "IExtent") == 0)
{
pRev = static_cast<IFastString*>(this);
}
else
{
return 0;
}

return pRev;
}

注意cast到IExtent的時候用了IFastString，因為IFastString 和 IOut都是從IExtent繼承的，寫IExtent的話不知道用哪個，用虛擬繼承可以使CFastString對象只有一份IExtent，為啥不用呢？ 你懂得。。。跟前面答案一樣，編譯器相關(guān)。

最后一個問題是delete的問題，用戶需要記得為每一個對象調(diào)用一次delete方法，而指針cast來cast去，想記得對象被delete沒有很難啊！ 怎么辦？ 用引用計數(shù)吧，把每個指針當做具有生命周期的實體，創(chuàng)建時候計數(shù)++，銷毀時候--，等到0的時候就delete對象。

大功告成，通過vptr和vtbl的二進制防火墻，我們做到了可重用的二進制組件，組件變化客戶無需重新編譯 。