Posted on 2006-07-04 17:59
奔跑的阿甘 閱讀(518)
評論(0) 編輯 收藏 引用 所屬分類:
COM/ATL
COM的由來
Michael 2006年07月04日
最近，公司的產品在支持SNA網絡時出現了一個怪異的問題，終端和主機連接總是無法建立，經過追查源碼發現應用客戶端在調用SNA網絡服務庫的接口時莫名其妙的改變了網絡服務對象的數據成員，實際上，該數據成員只有在對象構造函數中被初始化過一次，其他地方沒有任何寫操作。
根據應用客戶端對多網絡協議的支持代碼，我做了以下測試，Client應用調用一個Operate接口，由兩個不同的服務端實現：
Client包含IOperator接口文件，調用operate方法：
1?class?EXPORIMP?IOperator?{
?2?public:
?3?????IOperator();
?4?????~IOperator();
?5?????
?6?????long?operate(const?long?var1,?const?long?var2);
?7?????
?8?private:
?9?????int?a;
10?????int?b;
11?};
operate的第一個實現：server1.dll
?1class?EXPORIMP?IOperator?{
2??public:
3???????IOperator();
4???????~IOperator();
5???????
6???????long?operate(const?long?var1,?const?long?var2);
7???????
8???private:
9??????int?a;
10??????int?b;
11??};
operate的第二個實現：增強的server1.dll
?1class?EXPORIMP?IOperator?{
?2?public:
?3?????IOperator(); // Initialize szName, a, b
?4?????~IOperator();
?5?????
?6?????long?operate(const?long?var1,?const?long?var2); //access szName
?7?????
?8?private:
?9?????char?szName[256];
10?????int?a;
11?????int?b;
12?};
client通過server1.lib來實現接口調用，server1的發布者在發布dll后發現server1中存在某個BUG，或者為了改進operate的效率，因而引入了szName成員并更新了operate接口實現，然后重新發布了增強版的server1 DLL。客戶拿到新版本后很高興，但是，當他興致勃勃地替換掉老的DLL時，發現自己的客戶端再也跑不起來了，令人厭煩的異常！
我們發現兩種實現的唯一區別是私有數據成員的組成，但是DLL的PUBLIC接口沒有變化為什么會出現異常呢？
原來，客戶端在第一次編譯時引入老的server1.lib，并沒有準備為新的dll分配256個char變量，但是客戶端調用的新的dll接口時卻對不屬于自己的內存塊做了操作，其實，客戶端在創建IOperator對象時就出錯了！
我們稱以上的接口定義為“老”的接口定義方式，這種方式下，如果改變了數據成員而且公用接口對數據成員又做了操作，那么在不重新編譯客戶程序的情況下，客戶程序將毫無疑問的出現異常甚至崩潰。
封裝－C++的三大特性之一，在這里迷惑了我們的視眼。因為利用PRIVATE和PUBLIC關鍵字定義的封裝是“語法”上的封裝，也就是說，在同一工程內是不能夠直接訪問PRIVATE的成員的，否則編譯器會報告語法錯誤，實際上，編譯器在編譯重用庫的時候還是需要訪問重用類的所有成員（包括PRIVATE），以便在客戶中構造類對象。這樣，“接口”和“實現”實際上是一個東西。
“接口”和“實現”的真正分離，要求C++的“封裝”是種“二進制層次”的封裝。也就是說，不管重用類的實現如何改變，它提供的接口對于客戶來說都是靜止的。因此，我們把接口類和實現類分離的時候，要讓接口類的二進制布局不會隨著實現類的變化而變化。
下述對接口類和實現類的分離是成功的，因為不論實現類如何改進，接口IOperatorItf的內存布局從未改變。但是，一個殘酷的問題是，IOperatorItf類必須聲明IOperator的所有擁有的接口，對于一個稍微大型的類來說，這是個煩瑣的過程，而且，嵌套調用的開銷也不可忽略。
?1?class?EXPORIMP?IOperatorItf?{?? //接口類
?2?class?IOperator;
?3?IOperator*?m_pThis;
?4??public:
?5???????IOperator();
?6???????~IOperator();
?7???????
?8???????long?operate(const?long?var1,?const?long?var2);
?9??};
10?
11?class?EXPORIMP?IOperator?{?? //實現類
12??public:
13???????IOperator();
14???????~IOperator();
15???????
16???????long?operate(const?long?var1,?const?long?var2);
17???????
18???private:
19??????int?a;
20??????int?b;
21??};
這里還有個非常關鍵的問題，上述改進并沒有解決編譯器/鏈接器的標識符名字改編問題，這造成嚴重的編譯器/鏈接器依賴。
編譯器之間不可避免的在編譯細節上存在多種差異，然而，有一條特性卻是所有的編譯器都滿足的：“某個給定平臺上的所有C++編譯器都實現了同樣的虛函數調用機制”，即對于每個編譯器，類的對象在內存中如何表示，以及在運行時虛函數如何被動態調用，都是一樣的。這個特性非常漂亮的解決上述問題。
?1?//接口類
?2?class?IOperatorItf?{
?3??public:
?4???????vritual?long?operate(const?long?var1,?const?long?var2)＝0;
?5??};
?6?extern?"C"?IOperatorItf*?CreateOperatorInstance();
?7?
?8?//實現類
?9?class?IOperator?:?public?IOperatorItf?{
10??public:
11???????IOperator() {a=b=1};
12???????~IOperator();
13???????
14???????long?operate(const?long?var1,?const?long?var2) {return (a+b)};
15???????
16???private:
17??????int?a;
18??????int?b;
19??};
20?extern?"C"?IOperatorItf*?CreateOperatorInstance() { return (new IOperator)};
這里，接口類和實現類在定義上是獨立的，但是因為繼承，實現類的內存布局是接口類布局的二進制超集，這種“二進制層次”的繼承解決了我們前面幾種方案的所有問題。
“接口”和“實現”的分離是重用組件的核心，當我們學會用虛函數表來表達我們的接口時，COM已經在向我們招手了。
[完]