Basic Sample Senario :

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

解決方案：

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

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

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

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

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

                                          而后廠商更改了組件的實現

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

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

}

原來FastString對象大小為4字節，現在變為8字節，但是client端按照4字節分配對象， dll卻要向后面的4個字節存入一個指針，行為不可預料！

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

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

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

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

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

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

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

那么增加接口功能只能通過設計一個接口繼承另一個接口，或者讓類繼承多個接口來實現了。客戶可以在運行時通過RTTI來詢問對象，支持這個功能不，親？然而 ，RTTI也是一個compiler相關的東東，好吧，我們讓每個類自己實現RTTI，也就是實現一個dynamic_cast 方法， 用來將自己cast成為自己實現的接口，如果不支持則返回 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，為啥不用呢？ 你懂得。。。跟前面答案一樣，編譯器相關。

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

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