COM:The Component Object Model 組件對象模型
COM組件是遵循COM規範編寫、以Win32動態鏈接庫（DLL）或
可執行文件（EXE）形式發佈的可執行
二進制代碼，能夠滿足對組件架構的所有需求。遵循COM的規範標準，組件與應用、組件與組件之間可以互操作，極其方便地建立可伸縮的應用系統。COM是一種技術標準，其商業品牌則稱爲ActiveX。
近幾年來，組件在
軟件開發中得到了廣泛的應用，尤其是WindowsDNA將組件應用於Internet，進行各種事務處理，顯示出了強大的功能。從組件機制和接口標準方面探討組件不是一件輕鬆的事情，我們這裏僅從工程應用的範疇討論組件的開發與使用問題。
組件在應用開發方面具有以下特點：
----第一，
組件是與開發工具語言無關的。開發人員可以根據特定情況選擇特定語言工具實現組件的開發。對於Internet應用而言，完成事務邏輯處理計算任務的組件以MSVisualBasic進行開發是首選方案。其結果是開發迅速，調試方便，編譯之後的組件以二進制的形式發佈，可跨Windows平臺使用，而且
源程序代碼不會外泄，有效地保證了組件開發者的版權。
----第二，通過接口有效保證了組件的複用性。一個組件具有若干個接口，每個接口代表組件的某個屬性或方法。其他組件或應用程序可以設置或調用這些屬性和方法來進行特定的邏輯處理。組件和應用程序的連接是通過其接口實現的。負責集成的開發人員無需瞭解組件功能是如何實現的，只需簡單地創建組件對象並與其接口建立連接。在保證接口一致性的前提之下，可以調換組件、更新版本，也可以把組件安插在不同的應用系統中。
----第三，
組件運行效率高、便於使用和管理。因爲組件是
二進制代碼，運行效率比ASP
腳本高很多。核心的商務邏輯計算任務必須由組件來擔綱，ASP
腳本只起組裝的角色。而且組件在網絡上的位置可被透明分配，組件和使用它的程序能在同一進程中、不同進程中或不同機器上運行。組件之間是相互獨立的，MTS使對組件的管理更加簡便。組件對象通過一個內部引用計數器來管理它自己的生存期，這個計數器存放任何時候連接到該對象的客戶數。當
引用計數變爲0時，對象可以把自己從內存中釋放掉。這使程序員不必考慮與提供可共享資源有關的問題。
對於使用組件的集成開發者而言，一個組件就是一個接口集，只有通過接口才能與組件進行通信；而對於組件來說，接口是包含一個函數
指針數組的內存結構，每個數組元素的內容是一個由組件所實現的函數地址。在一個應用程序中，起決定作用的是組件的接口而不是組件本身。只要組件的接口保持不變，組件可以任意升級或更換，而應用程序不必做任何修改。接口將特定的行爲封裝起來，一方面使客戶可以用同樣的方式處理不同組件，一方面同一組件可以在不同的應用中使用。這些特點決定了組件必然有很好的重用性。
COM其實是微軟的一套模塊（各種exe和dll)交互的標準。
目前windows上有三套模塊交互的標準。第一套，dll，第二套COM，第三套.NET。衆所周知，win32是通過dll的導出表這種方式暴露的一整套非oop的函數，這是第一套的典型代表。第二套的代表
是DirectX等等。
要體會COM的目的，就必須從dll的不方便之處說起。第一，dll暴露的是純函數，沒有面向對象，當然，用c++做dll，類也是可以導出的，但這又牽涉到第二點。這個第二點就是，你如果導出一個指
針類型，vb等這些沒有指針的語言該怎麼處理呢？所以就需要一套獨立於所有語言的，數據交互格式。第三，導出的函數是線程安全嗎？也就是兩個線程可以同時訪問嗎？是可以再進入的嗎？
(reenterable)等等。這些問題dll的簡單的導出表是無法回答的，只能自己在兩個模塊的編程人員上協商好。既然如此，在模塊需要大量交互的情況下，編程人員還要做很多附加的工作，微軟索性就重新
修訂了一套模塊交互標準，把如上的這些因素都考慮進去，這就是COM的初衷。
在COM裏，一個接口可以看成一個dll的導出表，一個COM對象不再像dll那樣，只能有一張導出表了，COM對象可以有N個接口，每個接口可以導出一大溜函數。當然，COM必須規定這些接口的標
準，而且是在二進制上（彙編級的），也就是在內存上的每個接口是什麼樣子的（大概就是c++的虛函數表的樣子），因爲COM要跨語言。兩個語言如果對接口的內存模型不一致，一個call過去，結果
call錯了東西，不是函數，程序就崩潰了。同時，COM還要規定接口裏可用的各種數據格式。最後，COM提出了一個套間（apartment）的概念，套間說白了就是一種協調緩衝機制，在這種機制下，不
管對方是單線程訪問你，還是多線程，COM通過處理，最終都能轉成不會讓你崩潰的方式來訪問你的代碼，你的代碼就達到了線程透明。
線程透明，大概的過程如此，當多個線程同時訪問你代碼的時候，COM的套間的實現代碼就像小蜜一樣，會叫他們一個個排隊，這樣，最終到你代碼裏的，其實已經是單線程的調用了，所以，你的
代碼不會崩潰。COM的這種“小蜜”技術，既然可以實現線程透明，顯然還可以推廣，於是進程透明，網絡透明都可以做到了，中間步驟交給“小蜜”處理就好了。
在第二套模塊交互標準建立之後，微軟大部分的API就不單用dll函數的方式暴露了，更多是用COM來暴露，比如DirectX，瀏覽器的二次開發等等。
由上可知，如果你的程序交互簡單，大可不必用COM，用個dll導出表，足矣。如果程序導出的功能較多叫複雜，還是用COM這種方式暴露出接口爲好，這樣比較清晰。很多人說COM死了。我覺得
看你怎麼看，如果說COM功能會被移除，這幾乎是不可能的，因爲只是一套標準而已，而且還有諸多基於COM的程序。但微軟基本上不會用COM的這套標準來暴露API了，這可能是事實。
