面向?qū)ο蟮乃枷腚y以適應(yīng)這種分布式軟件模型，于是組件化程序設(shè)計思想得到了迅速的發(fā)展。

按照組件化的程序設(shè)計的思想，復(fù)雜的應(yīng)用程序被設(shè)計成一些小的，功能單一的組件模塊，這些組件模塊可以運(yùn)行在同一臺機(jī)器上，也可以運(yùn)行在不同的機(jī)器上。

為了實(shí)現(xiàn)這樣的應(yīng)用軟件，組建程序和組建程序之間需要一些極為細(xì)致的規(guī)范， 只有組件程序遵守了這些共同的規(guī)范，然間系統(tǒng)才能正常運(yùn)行。

為此，OMG和Microsoft分別提出了CORBA(Common Object Request Breaker Architecture)和COM(Component Object model)標(biāo)準(zhǔn)，目前CORBA模型主要應(yīng)用于UNIX操作系統(tǒng)平臺上，而COM 則主要應(yīng)用于Microsoft Windows操作系統(tǒng)平臺上。

在COM標(biāo)準(zhǔn)中，一個組件程序也被稱為一個模塊，它可以是一個動態(tài)連接庫(DLL), 被稱為進(jìn)程內(nèi)組件(in-of-process component)也可以是一個可執(zhí)行程序(EXE)，被稱為進(jìn)程外組件(out-of-process component).

COM對象是建立在二進(jìn)制可執(zhí)行代碼級的基礎(chǔ)上，而C++等語言中的對象是建立在源代碼級基礎(chǔ)上的，因此COM對象是語言無關(guān)的。這一特性使用不同編程語言開發(fā)的組件對象進(jìn)行交互成為可能。

在Microsoft Windows系統(tǒng)平臺上，COM技術(shù)被應(yīng)用于系統(tǒng)的各個層次，從底層的COM對象管理到上層的應(yīng)用程序交互都用到了COM標(biāo)準(zhǔn)。

概述

COM既提出了組件之間進(jìn)行交互的規(guī)范，也提供了實(shí)現(xiàn)交互的環(huán)境， 因?yàn)榻M件對象之間交互的規(guī)范不依賴于任何特定的語言，所以COM也可以是不同語言協(xié)作開發(fā)的一種標(biāo)準(zhǔn)。

OLE技術(shù)以COM規(guī)范為基礎(chǔ)，OLE充分發(fā)揮了COM標(biāo)準(zhǔn)的優(yōu)勢，使Windows操作系統(tǒng)上的應(yīng)用程序具有極強(qiáng)的可交互性。如果沒有OLE的支持，Windows操作系統(tǒng)則會遜色很多。

但是，COM規(guī)范并不局限于OLE技術(shù)，實(shí)際上，OLE技術(shù)只是COM的一個應(yīng)用而已，這幾年，OLE技術(shù)在進(jìn)行網(wǎng)絡(luò)互連是顯示出了很大的局限性，而COM則表現(xiàn)出了極強(qiáng)的適應(yīng)能力。

COM標(biāo)準(zhǔn)包括規(guī)范和實(shí)現(xiàn)兩大部分，規(guī)范部分定義了組件和組件之間通信的機(jī)制，這些規(guī)范不依賴于任何特定的語言和操作系統(tǒng)，只要按照該規(guī)范，任何語言都可以使用; COM標(biāo)準(zhǔn)的實(shí)現(xiàn)部分是COM庫，COM庫為COM規(guī)范的具體實(shí)現(xiàn)提供了一些核心服務(wù)。

COM是面對對象的軟件模型，因而對象是他的基本要素之一。類似于C++中對象的概念，對象是某個類(class)的一個實(shí)例;而類則是一組相關(guān)的數(shù)據(jù)和功能組和在一起的一個定義。使用對象的應(yīng)用(或另一個對象)成為客戶，有時也成為對象的用戶。

接口是一組邏輯上相關(guān)的函數(shù)集合，其函數(shù)也被稱為接口成員函數(shù)。對象通過接口成員函數(shù)為客戶提供各種形式的服務(wù)。

在COM模型中，對象本身對于客戶來說是不可見的，客戶請求服務(wù)時，只能通過接口進(jìn)行。每一個接口都由一個128位的全局唯一標(biāo)識符(GUID,Globally Unique Identifier)來標(biāo)識。客戶通過GUID獲得接口的指針，在通過接口指針，客戶就可以調(diào)用其相應(yīng)的成員函數(shù)。

一般來說，接口是不變的，只要客戶期望的接口在組建對象中還存在，它就可以繼續(xù)使用該接口所提供的服務(wù)。對象可以支持多個接口，因此對組件對象的升級可通過增加接口的辦法實(shí)現(xiàn)，這樣得到的新接口可以不影響老接口的使用。

客戶如何來標(biāo)識COM對象呢？與接口類似，每個對象也用一個128位GUID來標(biāo)識，稱為CLSID(class identifier,類標(biāo)識符或類ID)，用CLSID標(biāo)識對象可以保證(概率意義上)在全球范圍內(nèi)的唯一性。

只要系統(tǒng)中含有這類COM對象的信息，并包括COM對象所在的模塊文件(DLL或EXE文件)以及COM對象在代碼中的入口點(diǎn)，客戶程序就可以由此CLSID來創(chuàng)建COM對象。

那么客戶怎么使用COM對象所提供的服務(wù)呢？客戶獲得的又是什么呢？

實(shí)際上，客戶成功創(chuàng)建對象后，它得到的是一個指向?qū)ο竽硞€接口的指針，因?yàn)镃OM對象至少實(shí)現(xiàn)一個接口，所以客戶就可以調(diào)用該接口提供的所有服務(wù)。

但是COM對象可以有自己的狀態(tài)，正是這種狀態(tài)才使客戶感覺到COM對象的存在。如果客戶同時擁有兩個相同CLSID的對象，則兩個對象可以有不同的狀態(tài)，客戶完全不必關(guān)心COM對象是怎么實(shí)現(xiàn)的，以及兩個對象的狀態(tài)數(shù)據(jù)之間有什么關(guān)系(數(shù)組或者鏈表)。當(dāng)然，COM對象也可以是無狀態(tài)的，這種COM對象以提供功能服務(wù)為主，可以用來代替?zhèn)鹘y(tǒng)的API函數(shù)接口，使得應(yīng)用程序編程接口更為有序，組織層次性更強(qiáng)。

COM本身除了規(guī)范之外，也有實(shí)現(xiàn)的部分，其中包括一些核心的系統(tǒng)級代碼，也正是這部分核心代碼，才使得對象和客戶之間可通過接口在二進(jìn)制代碼級進(jìn)行交互 。

在Microsoft Windows操作系統(tǒng)環(huán)境下，這些庫以.dll文件的形勢存在，其中包括以下內(nèi)容:

(1) 提供了少量的API函數(shù)實(shí)現(xiàn)客戶和服務(wù)端COM應(yīng)用的創(chuàng)建過程。在客戶端，主要是一些創(chuàng)建函數(shù);而在服務(wù)器端，提供一些對象的訪問支持。

(2) COM通過注冊表查找本地服務(wù)器即EXE程序，以及程序名與CLSID的轉(zhuǎn)換等。

(3) 提供了一些標(biāo)準(zhǔn)的內(nèi)存控制方法，使應(yīng)用控制進(jìn)程中內(nèi)存的分配。

COM庫一般不在應(yīng)用程序?qū)訉?shí)現(xiàn)，而在操作系統(tǒng)層次上實(shí)現(xiàn)，因此一個操作系統(tǒng)只有一個COM庫實(shí)現(xiàn)。而且COM庫的實(shí)現(xiàn)必須依賴于具體的系統(tǒng)平臺，尤其是系統(tǒng)底層的一些標(biāo)準(zhǔn)。

COM庫可以保證所有的組件按照統(tǒng)一的方式進(jìn)行交互操作，而且它使我們在編寫COM應(yīng)用時，可以不用編寫為進(jìn)行COM通信而必需的大量基礎(chǔ)代碼，而是直接利用COM庫提供的API進(jìn)行編程，從而大大加快了開發(fā)的速度。例如，現(xiàn)在COM庫的版本都支持遠(yuǎn)程組件即分布式COM，我們不用編寫任何網(wǎng)絡(luò)或者RPC(remote procedure call)的代碼，就可以實(shí)現(xiàn)在網(wǎng)絡(luò)上進(jìn)行程序之間的通信。

如果我們用面向?qū)ο笳Z言來實(shí)現(xiàn)COM對象，則很自然可以用類類定義對象。在C語言中，對象的概念可能變成一個邏輯概念，如果兩個對象同時存在，則在接口實(shí)現(xiàn)中必須明確知道所進(jìn)行的操作是針對哪個對象的，這個過程可由COM接口的定義保證。

COM規(guī)范使用GUID來標(biāo)識COM對象的思想源于OSF(Open Software Foundation)采用的UUID(Universallz Unique Identifier), UUID被定義為DCE(Distributed Computing Environment)的一部分，主要用于表識RPC通信的雙方。

除了封裝性和重用性，C++對象還有一個重要特性是多態(tài)性。正是C++對象的多態(tài)性，才體現(xiàn)了C++語言用類描述事物的高度抽象的特征;COM對象也 具有多態(tài)性，但這種多態(tài)性需要通過COM對象所具有的接口才能體現(xiàn)出來，就像C++對象的多態(tài)性需要通過其(virtual)函數(shù)才能體現(xiàn)一樣。

從API到COM接口

假如我們要實(shí)現(xiàn)一個字處理應(yīng)用系統(tǒng)，它需要一個查字典的功能，按照組件化程序設(shè)計的方法，自然應(yīng)該把查字典的功能放到一個組件(.dll)程序中實(shí)現(xiàn)。如果以后字典程序的查找算法或者字典庫改變了，只要應(yīng)用程序和組件之間的接口不變，則新的組件程序仍然可以被應(yīng)用系統(tǒng)使用。這就是采用組件程序帶來的靈活性。

為了把應(yīng)用系統(tǒng)和組件程序連接起來，又能使它們協(xié)同工作，最簡單的做法就是先定義一組查字典的函數(shù)，而且這組函數(shù)盡可能一般化，不要加入特定的與字典庫相關(guān)的知識。

函數(shù)
 功能說明
 
Initialize
 初始化
 
LoadLibrary
 裝入字典庫
 
InsertWord
 插入一個單詞
 
DeleteWord
 刪除一個單詞
 
LookupWord
 查找單詞
 
RestoreLibrary
 把內(nèi)存中的字典庫存入指定的文件中
 
FreeLibrary
 釋放字典庫
 

平面型的API接口層可以很好地把兩個程序連接起來，但存在以下一些問題：

(1) 當(dāng)API函數(shù)非常多時，使用會非常不方便，需要對函數(shù)進(jìn)行組織。

(2) API函數(shù)需要標(biāo)準(zhǔn)化，按照統(tǒng)一的調(diào)用方式進(jìn)行處理，以適應(yīng)不同的語言編程實(shí)現(xiàn)。參數(shù)的傳遞順序，參數(shù)類型，寒暑返回處理都需要標(biāo)準(zhǔn)化。

COM定義了一套完整的接口規(guī)范，不僅可以彌補(bǔ)以上API作為組件借口的不足，還充分發(fā)揮了組件對象的優(yōu)勢，并實(shí)現(xiàn)了組件對象的多態(tài)性。

接口定義和標(biāo)識
從技術(shù)上講，接口是包含了一組函數(shù)的數(shù)據(jù)結(jié)構(gòu)，通過這組數(shù)據(jù)結(jié)構(gòu)，客戶代碼可以調(diào)用組件對象的功能。接口定義了一組成員函數(shù)，這組成員函數(shù)是組件對象暴露出來的所有信息，客戶程序利用這些函數(shù)或的組件對象的服務(wù)。

客戶程序用一個指向接口數(shù)據(jù)機(jī)構(gòu)的指針來調(diào)用接口成員函數(shù)。接口指針實(shí)際上又指向另一個指針，這第二個指針指向一組函數(shù)，稱為接口函數(shù)表(虛函數(shù)表)，接口函數(shù)表中每一項(xiàng)為4個字節(jié)長的函數(shù)指針，每個函數(shù)指針與對象的具體實(shí)現(xiàn)連接起來。通過這種方式，客戶只要獲得了接口指針，就可以調(diào)用到對象的實(shí)際功能。

對于一個接口來說，他的虛函數(shù)表vtable是確定的，因此接口的成員函數(shù)個數(shù)是不變的，而且成員函數(shù)的先后順序也是不變的;對于每個成員函數(shù)來說，其參數(shù)和返回值也是確定的。

在一個接口的定義中，所有這些信息都必須在二進(jìn)制一級確定，不管什么語言，只要能支持這樣的內(nèi)存結(jié)構(gòu)描述，也就是能夠支持“structure“或“record“類型，并且這種類型能夠包含雙重的指向函數(shù)指針表的成員，則它就可以支持接口的描述，從而可以用于編寫COM組件或者使用COM組件。

接口描述語言IDL

COM規(guī)范在采用OSF的DCE規(guī)范描述遠(yuǎn)程調(diào)用接口IDL的基礎(chǔ)上，進(jìn)行擴(kuò)展形成了COM接口的描述語言。

COM規(guī)范使用的IDL接口描述語言不僅可用于定義COM接口，同時還定義了一些常用的數(shù)據(jù)類型，也可以描述自定義的數(shù)據(jù)結(jié)構(gòu)，對于接口成員函數(shù)，我們可以指定每個參數(shù)的類型，輸入輸出特性，甚至支持可變長度的數(shù)組的描述。IDL支持指針類型，與C/C++很類似。

Microsoft Visual C++提供了MIDL工具，可以把IDL接口描述文件編譯成C/C++兼容的接口描述頭文件(.h)。

IUnknown的定義(IDL):

interface IUnknown
{

HRESULT QueryInterface([in] REFIID iid, [out] void **ppv);
ULONG AddRef(void);
ULONG Release(void);
}

IUnknown的定義(C++):

class IUnknown
{

Public:
virtual HRESULT _stdcall QueryInterface([in] REFIID iid, [out] void **ppv)=0;
virtual ULONG _stdcall AddRef(void)=0;
virtual ULONG _stdcall Release(void)=0;
}

進(jìn)程內(nèi)組件

因?yàn)檫M(jìn)程內(nèi)組件和客戶程序運(yùn)行在同一個進(jìn)程地址空間中，所以一旦客戶程序與組件程序建立起通信關(guān)系之后，客戶程序得到的接口指針指向組件程序中接口的vtable，這個vtable包含了所有成員函數(shù)地址，客戶代碼可以直接調(diào)用這些成員函數(shù)，所以其效率非常高。

因?yàn)镈LL程序是在運(yùn)行時刻被客戶裝入到內(nèi)存中的，所以DLL模塊本身也是獨(dú)立的，它并不依賴于客戶程序。

在C++語言中，為了使編制的DLL程序更為通用，一般指定DLL的引出函數(shù)使用_stdcall調(diào)用習(xí)慣，如果使用了_cdecl調(diào)用習(xí)慣，則有些編程語言環(huán)境就不能使用這些DLL程序。C++編譯器為DLL程序的每個引出函數(shù)生成了一個修飾名，這些修飾名對于不同的編譯器并不兼容，因此，從通用性角度出發(fā)，我們在每個函數(shù)定義前加上extern ?C“ 說明符。在Visual C++ 開發(fā)環(huán)境中，下面的說明語句可以很好的說明一個引出函數(shù)：

extern ? C“ int _stdcall MyFunction(int n);

為了編制DLL程序，我們可以按照這樣的步驟：

(1) 創(chuàng)建一個DLL工程

(2) 對每個引出函數(shù)，使用extern ? C“說明符，以及_stdcall修飾符，如上面對MyFunction函數(shù)的說明。

(3) 按照傳統(tǒng)的編程方法，我們還應(yīng)該編寫一個DEF文件，用來描述DLL程序的模塊信息。在Win32平臺上，我們可以不使用DEF文件，而是直接在函數(shù)說明時使用_declspec(dllexport)說明符，例如：

extern ? C“_declspec(dllexport) int _stdcall MyFunction(int n);

按照這樣的方法建立起來的DLL模塊可以被其他程序調(diào)用，因?yàn)镃++連接器會把所有引出函數(shù)的信息連接到最終的目標(biāo)代碼中。

從客戶程序一方來看，有三個系統(tǒng)函數(shù)可用于操作DLL程序，LoadLibrary, GetProcAddress, 和FreeLibrary。

一般地，對于DLL程序的使用過程按照這樣的步驟進(jìn)行：

首先，客戶程序使用LoadLibrary函數(shù)裝入DLL，該函數(shù)返回模塊的實(shí)例句柄，供以后操作該模塊使用。

然后，客戶程序可以調(diào)用GetProcAddress函數(shù)獲得DLL中引出的函數(shù)的地址，我們既可以按函數(shù)的序號(在DEF文件中指定)也可以按函數(shù)的名字來獲取引出函數(shù)的地址，因?yàn)榭蛻舫绦蚝虳LL程序在相同的內(nèi)存地址空間中，所以客戶程序可以直接調(diào)用這些引出函數(shù)。

最后FreeLibrary，把DLL程序卸出內(nèi)存，以便釋放資源。

說明：

(1) DLL程序不僅可以引出函數(shù)，也可以引出全局變量，因?yàn)榭蛻舫绦蚝虳LL程序在同一個地址空間，所以，把DLL中的全局變量引出到客戶程序中是有意義的。引用的方法并不復(fù)雜，或者把變量名放到DEF文件的EXPORTS部分，并加上DATA選項(xiàng); 或者在變量說明前面加上_declspec(dllexport)說明符。

(2) DumpBin 通過/Exports選項(xiàng)可以列出DLL程序中的所有被引出的信息。

(3) 客戶程序本身也可以是一個DLL程序，但它一定先被裝入到進(jìn)程空間中，以便可以調(diào)用系統(tǒng)函數(shù)操作作為服務(wù)程序的DLL模塊。

進(jìn)程外組件
因?yàn)檫M(jìn)程外組件程序和客戶程序位于不同的進(jìn)程空間之中，他們使用不同的地址空間，所以組件和客戶之間的通信必須跨越進(jìn)程邊界，這就涉及到以下一些問題：

(1) 一個進(jìn)程如何調(diào)用另外一個進(jìn)程中的函數(shù)

(2) 參數(shù)如何從一個進(jìn)程被傳遞到另外一個進(jìn)程中

Windows平臺上，在不同進(jìn)程之間進(jìn)行通信的辦法很多，包括DDE, named pipe,或者共享內(nèi)存等等，COM采用了LPC(Local Procedure Call)和RPC(Remote Procedure Call)

RegEdit可檢查CLSID子鍵下的COM對象(63頁)
Microsoft Visual C++提供OleView.exe，可列出當(dāng)前機(jī)器上的所有類別信息，以及每一種類別下的組件對象列表。

RegSvr32 D:\DicComp\DictComp.dll

RegSvr32 /u D:\DicComp\DictComp.dll

DLL組件必須有DllRegisterServer和DllUnregisterServer兩個用于注冊的入口函數(shù)，才能用RegSvr32注冊。

COM規(guī)定，支持自注冊的進(jìn)程外組件必須支持兩個命令行參數(shù)/RegServer和/UnregServer，以便完成注冊或注銷操作。
Class Factory

實(shí)際上，客戶程序并不直接調(diào)用組件程序的引出函數(shù)，它調(diào)用COM庫的函數(shù)進(jìn)行組件對象的創(chuàng)建工作，COM庫的創(chuàng)建函數(shù)根據(jù)注冊表的信息調(diào)用組件程序的入口函數(shù)來創(chuàng)建組件對象。組件程序需要提供一個標(biāo)準(zhǔn)的入口函數(shù)DLLGetObjectClass，用于提供本組程序的組件信息。

Class Factory和DLLGetObjectClass函數(shù)
類廠是COM對象的生產(chǎn)基地，COM庫通過類廠創(chuàng)建COM對象; 對應(yīng)每一個COM類，有一個類廠專門用于該COM類的對象創(chuàng)操作。類廠本身也是一個COM對象，它支持一個特殊的接口：IClassFactory，其定義如下：

Class IClassFactory : public IUnknown

{
virtual HRESULT _stdcall CreateInstance(IUnknown *pUnknownOuter, const IID& iid, void **ppv) = 0;
virtual HRESULT _stdcall LockServer(BOOL bLock) = 0;

};

接口IClassFactory有一個重要的成員函數(shù)CreateInstance，用于創(chuàng)建對應(yīng)的COM對象。因?yàn)槊總€類廠之針對特定的COM類對象，所以CreateInstance成員函數(shù)知道該創(chuàng)建什么樣的COM對象。在CreateInstance成員函數(shù)的參數(shù)中，第一個參數(shù)pUnknownOuter用于對象被聚合的情形，沒有聚合設(shè)成NULL。IClassFactory的另一個成員函數(shù)LockServer用于控制組建的生存周期。

因?yàn)轭悘S本身也是個COM對象，它被用于其它COM對象的創(chuàng)建過程，那么類廠對象又由誰來創(chuàng)建呢？答案是DLLGetClassObject引出函數(shù)。DLLGetClassObject函數(shù)并不是COM庫的函數(shù)，而是由組件程序?qū)崿F(xiàn)的引出函數(shù)，我們先看一下DLLGetClassObject函數(shù)的原型：

HRESULT DLLGetClassObject(const CLSID& clsid,
Const IID& iid,
(void **) ppv
);

COM庫在接到對象創(chuàng)建的指令后，它要調(diào)進(jìn)程內(nèi)組件的DLLGetClassObject函數(shù)，由該函數(shù)創(chuàng)類廠對象，并返回類廠對象的接口指針，COM庫或者客戶一旦有了類廠的接口指針，它們就可以通過類廠接口IClassFactory的成員函數(shù)CreateInstance創(chuàng)建相應(yīng)的COM對象。

COM庫與類廠的交互（67頁）
在COM庫中，有三個API函數(shù)可用于對象的創(chuàng)建，它們分別是CoGetClassObject, CoCreateInstance和CoCreateInstanceEx。通常情況下，客戶程序調(diào)用其中之一完成對象的創(chuàng)建，并返回對象的初始接口指針。COM庫與類廠也通過這三個函數(shù)進(jìn)行交互。