我見過很多人學COM，看完一本書後覺得對COM的原理比較瞭解了，COM也不過如此，可是就是不知道該怎麼編程序，我自己也有這種情況，我也是經歷了這樣的階段走過來的。要學COM的基本原理，我推薦的書是《COM技術內幕》。但僅看這樣的書是遠遠不夠的，我們最終的目的是要學會怎麼用COM去編程序，而不是拼命的研究COM本身的機制。所以我個人覺得對COM的基本原理不需要花大量的時間去追根問底，沒有必要，是喫力不討好的事。其實我們只需要掌握幾個關鍵概念就夠了。這裏我列出了一些我自己認爲是用VC編程所必需掌握的幾個關鍵概念。(這裏所說的均是用C++語言條件下的COM編程方式)
(1) COM組件實際上是一個C++類，而接口都是純虛類。組件從接口派生而來。我們可以簡單的用純粹的C++的語法形式來描述COM是個什麼東西：
class IObject
{
public:
virtual Function1(...) = 0;
virtual Function2(...) = 0;
....
};
class MyObject : public IObject
{
public:
virtual Function1(...){...}
virtual Function2(...){...}
....
};
看清楚了嗎？IObject就是我們常說的接口，MyObject就是所謂的COM組件。切記切記接口都是純虛類，它所包含的函數都是純虛函數，而且它沒有成員變量。而COM組件就是從這些純虛類繼承下來的派生類，它實現了這些虛函數，僅此而已。從上面也可以看出，COM組件是以 C++爲基礎的，特別重要的是虛函數和多態性的概念，COM中所有函數都是虛函數，都必須通過虛函數表VTable來調用，這一點是無比重要的，必需時刻牢記在心。爲了讓大家確切瞭解一下虛函數表是什麼樣子，從《COM＋技術內幕》中COPY了下面這個示例圖：
(2) COM組件有三個最基本的接口類，分別是IUnknown、IClassFactory、IDispatch。
COM規範規定任何組件、任何接口都必須從IUnknown繼承，IUnknown包含三個函數，分別是 QueryInterface、AddRef、Release。這三個函數是無比重要的，而且它們的排列順序也是不可改變的。QueryInterface用於查詢組件實現的其它接口，說白了也就是看看這個組件的父類中還有哪些接口類，AddRef用於增加引用計數，Release用於減少引用計數。引用計數也是COM中的一個非常重要的概念。大體上簡單的說來可以這麼理解，COM組件是個DLL，當客戶程序要用它時就要把它裝到內存裏。另一方面，一個組件也不是隻給你一個人用的，可能會有很多個程序同時都要用到它。但實際上DLL只裝載了一次，即內存中只有一個COM組件，那COM組件由誰來釋放？由客戶程序嗎？不可能，因爲如果你釋放了組件，那別人怎麼用，所以只能由COM組件自己來負責。所以出現了引用計數的概念，COM維持一個計數，記錄當前有多少人在用它，每多一次調用計數就加一，少一個客戶用它就減一，當最後一個客戶釋放它的時侯，COM知道已經沒有人用它了，它的使用已經結束了，那它就把它自己給釋放了。引用計數是COM編程裏非常容易出錯的一個地方，但所幸VC的各種各樣的類庫裏已經基本上把AddRef的調用給隱含了，在我的印象裏，我編程的時侯還從來沒有調用過AddRef，我們只需在適當的時侯調用Release。至少有兩個時侯要記住調用Release，第一個是調用了 QueryInterface以後，第二個是調用了任何得到一個接口的指針的函數以後，記住多查MSDN 以確定某個函數內部是否調用了AddRef，如果是的話那調用Release的責任就要歸你了。 IUnknown的這三個函數的實現非常規範但也非常煩瑣，容易出錯，所幸的事我們可能永遠也不需要自己來實現它們。
IClassFactory的作用是創建COM組件。我們已經知道COM組件實際上就是一個類，那我們平常是怎麼實例化一個類對象的？是用‘new’命令!很簡單吧，COM組件也一樣如此。但是誰來new它呢？不可能是客戶程序，因爲客戶程序不可能知道組件的類名字，如果客戶知道組件的類名字那組件的可重用性就要打個大大的折扣了，事實上客戶程序只不過知道一個代表着組件的128位的數字串而已，這個等會再介紹。所以客戶無法自己創建組件，而且考慮一下，如果組件是在遠程的機器上，你還能new出一個對象嗎？所以創建組件的責任交給了一個單獨的對象，這個對象就是類廠。每個組件都必須有一個與之相關的類廠，這個類廠知道怎麼樣創建組件，當客戶請求一個組件對象的實例時，實際上這個請求交給了類廠，由類廠創建組件實例，然後把實例指針交給客戶程序。這個過程在跨進程及遠程創建組件時特別有用，因爲這時就不是一個簡單的new操作就可以的了，它必須要經過調度，而這些複雜的操作都交給類廠對象去做了。IClassFactory最重要的一個函數就是CreateInstance，顧名思議就是創建組件實例，一般情況下我們不會直接調用它，API函數都爲我們封裝好它了，只有某些特殊情況下才會由我們自己來調用它，這也是VC編寫COM組件的好處，使我們有了更多的控制機會，而VB給我們這樣的機會則是太少太少了。
IDispatch叫做調度接口。它的作用何在呢？這個世上除了C++還有很多別的語言，比如VB、 VJ、VBScript、JavaScript等等。可以這麼說，如果這世上沒有這麼多亂七八糟的語言，那就不會有IDispatch。:-) 我們知道COM組件是C++類，是靠虛函數表來調用函數的，對於VC來說毫無問題，這本來就是針對C++而設計的，以前VB不行，現在VB也可以用指針了，也可以通過VTable來調用函數了，VJ也可以，但還是有些語言不行，那就是腳本語言，典型的如 VBScript、JavaScript。不行的原因在於它們並不支持指針，連指針都不能用還怎麼用多態性啊，還怎麼調這些虛函數啊。唉，沒辦法，也不能置這些腳本語言於不顧吧，現在網頁上用的都是這些腳本語言，而分佈式應用也是COM組件的一個主要市場，它不得不被這些腳本語言所調用，既然虛函數表的方式行不通，我們只能另尋他法了。時勢造英雄，IDispatch應運而生。:-) 調度接口把每一個函數每一個屬性都編上號，客戶程序要調用這些函數屬性的時侯就把這些編號傳給IDispatch接口就行了，IDispatch再根據這些編號調用相應的函數，僅此而已。當然實際的過程遠比這複雜，僅給一個編號就能讓別人知道怎麼調用一個函數那不是天方夜潭嗎，你總得讓別人知道你要調用的函數要帶什麼參數，參數類型什麼以及返回什麼東西吧，而要以一種統一的方式來處理這些問題是件很頭疼的事。IDispatch接口的主要函數是Invoke，客戶程序都調用它，然後Invoke再調用相應的函數，如果看一看MS的類庫裏實現 Invoke的代碼就會驚歎它實現的複雜了，因爲你必須考慮各種參數類型的情況，所幸我們不需要自己來做這件事，而且可能永遠也沒這樣的機會。:-)
(3) dispinterface接口、Dual接口以及Custom接口
這一小節放在這裏似乎不太合適，因爲這是在ATL編程時用到的術語。我在這裏主要是想談一下自動化接口的好處及缺點，用這三個術語來解釋可能會更好一些，而且以後遲早會遇上它們，我將以一種通俗的方式來解釋它們，可能並非那麼精確，就好象用僞代碼來描述算法一樣。-:)
所謂的自動化接口就是用IDispatch實現的接口。我們已經講解過IDispatch的作用了，它的好處就是腳本語言象VBScript、 JavaScript也能用COM組件了，從而基本上做到了與語言無關它的缺點主要有兩個，第一個就是速度慢效率低。這是顯而易見的，通過虛函數表一下子就可以調用函數了，而通過Invoke則等於中間轉了道手續，尤其是需要把函數參數轉換成一種規範的格式纔去調用函數，耽誤了很多時間。所以一般若非是迫不得已我們都想用VTable的方式調用函數以獲得高效率。第二個缺點就是隻能使用規定好的所謂的自動化數據類型。如果不用IDispatch我們可以想用什麼數據類型就用什麼類型，VC會自動給我們生成相應的調度代碼。而用自動化接口就不行了，因爲Invoke的實現代碼是VC事先寫好的，而它不能事先預料到我們要用到的所有類型，它只能根據一些常用的數據類型來寫它的處理代碼，而且它也要考慮不同語言之間的數據類型轉換問題。所以VC自動化接口生成的調度代碼只適用於它所規定好的那些數據類型，當然這些數據類型已經足夠豐富了，但不能滿足自定義數據結構的要求。你也可以自己寫調度代碼來處理你的自定義數據結構，但這並不是一件容易的事。考慮到IDispatch的種種缺點(它還有一個缺點，就是使用麻煩，:-) )現在一般都推薦寫雙接口組件，稱爲dual接口，實際上就是從IDispatch繼承的接口。我們知道任何接口都必須從 IUnknown繼承，IDispatch接口也不例外。那從IDispatch繼承的接口實際上就等於有兩個基類，一個是IUnknown，一個是IDispatch，所以它可以以兩種方式來調用組件，可以通過 IUnknown用虛函數表的方式調用接口方法，也可以通過IDispatch::Invoke自動化調度來調用。這就有了很大的靈活性，這個組件既可以用於C++的環境也可以用於腳本語言中，同時滿足了各方面的需要。
相對比的，dispinterface是一種純粹的自動化接口，可以簡單的就把它看作是IDispatch接口 (雖然它實際上不是的)，這種接口就只能通過自動化的方式來調用，COM組件的事件一般都用的是這種形式的接口。
Custom接口就是從IUnknown接口派生的類，顯然它就只能用虛函數表的方式來調用接口了
(4) COM組件有三種，進程內、本地、遠程。對於後兩者情況必須調度接口指針及函數參數。
COM是一個DLL，它有三種運行模式。它可以是進程內的，即和調用者在同一個進程內，也可以和調用者在同一個機器上但在不同的進程內，還可以根本就和調用者在兩臺機器上。這裏有一個根本點需要牢記，就是COM組件它只是一個DLL，它自己是運行不起來的，必須有一個進程象父親般照顧它纔行，即COM組件必須在一個進程內.那誰充當看護人的責任呢？先說說調度的問題。調度是個複雜的問題，以我的知識還講不清楚這個問題，我只是一般性的談談幾個最基本的概念。我們知道對於WIN32程序，每個進程都擁有4GB的虛擬地址空間，每個進程都有其各自的編址，同一個數據塊在不同的進程裏的編址很可能就是不一樣的，所以存在着進程間的地址轉換問題。這就是調度問題。對於本地和遠程進程來說，DLL 和客戶程序在不同的編址空間，所以要傳遞接口指針到客戶程序必須要經過調度。Windows 已經提供了現成的調度函數，就不需要我們自己來做這個複雜的事情了。對遠程組件來說函數的參數傳遞是另外一種調度。DCOM是以RPC爲基礎的，要在網絡間傳遞數據必須遵守標準的網上數據傳輸協議，數據傳遞前要先打包，傳遞到目的地後要解包，這個過程就是調度，這個過程很複雜，不過Windows已經把一切都給我們做好了，一般情況下我們不需要自己來編寫調度DLL。
我們剛說過一個COM組件必須在一個進程內。對於本地模式的組件一般是以EXE的形式出現，所以它本身就已經是一個進程。對於遠程DLL，我們必須找一個進程，這個進程必須包含了調度代碼以實現基本的調度。這個進程就是dllhost.exe。這是COM默認的DLL代理。實際上在分佈式應用中，我們應該用MTS來作爲DLL代理，因爲MTS有着很強大的功能，是專門的用於管理分佈式DLL組件的工具。
調度離我們很近又似乎很遠，我們編程時很少關注到它，這也是COM的一個優點之一，既平臺無關性，無論你是遠程的、本地的還是進程內的，編程是一樣的，一切細節都由COM自己處理好了，所以我們也不用深究這個問題，只要有個概念就可以了，當然如果你對調度有自己特殊的要求就需要深入瞭解調度的整個過程了，這裏推薦一本《COM+技術內幕》，這絕對是一本講調度的好書。
(5) COM組件的核心是IDL。
我們希望軟件是一塊塊拼裝出來的，但不可能是沒有規定的胡亂拼接，總是要遵守一定的標準，各個模塊之間如何才能親密無間的合作，必須要事先共同制訂好它們之間交互的規範，這個規範就是接口。我們知道接口實際上都是純虛類，它裏面定義好了很多的純虛函數，等着某個組件去實現它，這個接口就是兩個完全不相關的模塊能夠組合在一起的關鍵試想一下如果我們是一個應用軟件廠商，我們的軟件中需要用到某個模塊，我們沒有時間自己開發，所以我們想到市場上找一找看有沒有這樣的模塊，我們怎麼去找呢？也許我們需要的這個模塊在業界已經有了標準，已經有人制訂好了標準的接口，有很多組件工具廠商已經在自己的組件中實現了這個接口，那我們尋找的目標就是這些已經實現了接口的組件，我們不關心組件從哪來，它有什麼其它的功能，我們只關心它是否很好的實現了我們制訂好的接口。這種接口可能是業界的標準，也可能只是你和幾個廠商之間內部制訂的協議，但總之它是一個標準，是你的軟件和別人的模塊能夠組合在一起的基礎，是COM組件通信的標準。
COM具有語言無關性，它可以用任何語言編寫，也可以在任何語言平臺上被調用。但至今爲止我們一直是以C++的環境中談COM，那它的語言無關性是怎麼體現出來的呢？或者換句話說，我們怎樣才能以語言無關的方式來定義接口呢？前面我們是直接用純虛類的方式定義的，但顯然是不行的，除了C++誰還認它呢？正是出於這種考慮，微軟決定採用IDL來定義接口。說白了，IDL實際上就是一種大家都認識的語言，用它來定義接口，不論放到哪個語言平臺上都認識它。我們可以想象一下理想的標準的組件模式，我們總是從IDL開始，先用IDL制訂好各個接口，然後把實現接口的任務分配不同的人，有的人可能善長用VC，有的人可能善長用VB，這沒關係，作爲項目負責人我不關心這些，我只關心你把最終的DLL 拿給我。這是一種多麼好的開發模式，可以用任何語言來開發，也可以用任何語言來欣賞你的開發成果。
(6) COM組件的運行機制，即COM是怎麼跑起來的。
這部分我們將構造一個創建COM組件的最小框架結構，然後看一看其內部處理流程是怎樣的
IUnknown *pUnk=NULL;
IObject *pObject=NULL;
CoInitialize(NULL);
CoCreateInstance(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IUnknown, (void**)&pUnk);
pUnk->QueryInterface(IID_IOjbect, (void**)&pObject);
pUnk->Release();
pObject->Func();
pObject->Release();
CoUninitialize();
這就是一個典型的創建COM組件的框架，不過我的興趣在CoCreateInstance身上，讓我們來看看它內部做了一些什麼事情。以下是它內部實現的一個僞代碼:
CoCreateInstance(....)
{
.......
IClassFactory *pClassFactory=NULL;
CoGetClassObject(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, (void **)&pClassFactory);
pClassFactory->CreateInstance(NULL, IID_IUnknown, (void**)&pUnk);
pClassFactory->Release();
........
}
這段話的意思就是先得到類廠對象，再通過類廠創建組件從而得到IUnknown指針。繼續深入一步，看看CoGetClassObject的內部僞碼：
CoGetClassObject(.....)
{
//通過查註冊表CLSID_Object，得知組件DLL的位置、文件名
//裝入DLL庫
//使用函數GetProcAddress(...)得到DLL庫中函數DllGetClassObject的函數指針。
//調用DllGetClassObject
}
DllGetClassObject是幹什麼的，它是用來獲得類廠對象的。只有先得到類廠才能去創建組件.
下面是DllGetClassObject的僞碼：
DllGetClassObject(...)
{
......
CFactory* pFactory= new CFactory; //類廠對象
pFactory->QueryInterface(IID_IClassFactory, (void**)&pClassFactory);
//查詢IClassFactory指針
pFactory->Release();
......
}
CoGetClassObject的流程已經到此爲止，現在返回CoCreateInstance，看看CreateInstance的僞碼：
CFactory::CreateInstance(.....)
{
...........
CObject *pObject = new CObject; //組件對象
pObject->QueryInterface(IID_IUnknown, (void**)&pUnk);
pObject->Release();
...........
}
下圖是從COM+技術內幕中COPY來的一個例圖，從圖中可以清楚的看到CoCreateInstance的整個流程。
(7) 一個典型的自注冊的COM DLL所必有的四個函數
DllGetClassObject:用於獲得類廠指針
DllRegisterServer:註冊一些必要的信息到註冊表中
DllUnregisterServer:卸載註冊信息
DllCanUnloadNow:系統空閒時會調用這個函數，以確定是否可以卸載DLL
DLL還有一個函數是DllMain,這個函數在COM中並不要求一定要實現它，但是在VC生成的組件中自動都包含了它，它的作用主要是得到一個全局的實例對象。
(8) 註冊表在COM中的重要作用
首先要知道GUID的概念，COM中所有的類、接口、類型庫都用GUID來唯一標識，GUID是一個128位的字串，根據特製算法生成的GUID可以保證是全世界唯一的。 COM組件的創建，查詢接口都是通過註冊表進行的。有了註冊表，應用程序就不需要知道組件的DLL文件名、位置，只需要根據CLSID查就可以了。當版本升級的時侯，只要改一下注冊表信息就可以神不知鬼不覺的轉到新版本的DLL。
本文是本人一時興起的塗鴨之作，講得並不是很全面，還有很多有用的體會沒寫出來，以後如果有時間有興趣再寫出來。希望這篇文章能給大家帶來一點用處，那我一晚上的辛苦就沒有白費了。-:)