【 某某提到: 】
: 一般說COM復雜，首先是名詞太多，其次是基于ATL的實現比較難懂
: 這并不是COM本身復雜，而是C++已經落后于時代了。所以ATL看起來才會像天書一般
雖然對于全新的工程項目，推薦通過.net實現，但是，只要你工作在Windows平臺上，必然會遇到和COM相關的技術和機制，無論是大量的legacy的工程和代碼，還是作為OS重要功能以及native組件的首選交互形式和接口暴露方式，比如DirectX API，比如一些WMI的API；最有趣的是，即使是.net的核心CLR本身也是一個COM組件，可以通過Host相關接口讓native應用來加載，以在當前進程中啟動整個CLR的虛擬執行環境或者叫托管執行環境(managed executive environment)。
把握COM有兩點很關鍵，
1）Interface-based design，從設計和編碼思路上就是要完全基于接口；
2）VirtualTable-based binary compatibility, 實現上無論何種語言或者機制，只要符合基于虛表的二進制兼容規范，就都可以實施；
COM僅僅是個規范，基于COM的具體技術非常之多，OLE，Automation，Structural storage，ActiveX...汗牛充棟，還有COM+，這個是提供企業級開發必備的一些基礎功能和設施，比如，事務管理機制，對象池，安全管理，消息隊列...需要指出，目前即便是.net Framework也沒有實現COM+所提供這些機制，只是簡單的封裝了后者。
COM技術中可能有一些比較困難的地方，接口的一致性，對象的聚合和生命周期，套間，跨套間的接口訪問，名字對象，等等；這些并不是COM規范人為制造的困難，而是為了設計和提供，可以跨進程和機器邊界，跨異構平臺（當然必須實現了COM所規定的基礎服務），透明化具體對象類型及對象生命周期，便于統一部署和版本管理的組件技術，所必須付出的代價，這個代價從開發人員角度看具體表現為，概念理解的困難以及具體二進制實現的困難；
不過從另一個角度看，COM已經很容易了，
a) COM規范已把要達致這些目標的系統，所必須提供的接口和特性抽象了出來，只不過為了表達這些抽象的概念而新造的術語名詞有些陌生和突兀；如果讓遇到相似問題的每一個設計和開發人員都自己來做抽象，未必會生成更好的方案；
b) 為了幫助設計和開發人員，人們提供了很多的開發庫，以提高COM開發的正確性和效率；最顯著的就是MFC中關于COM/OLE的輔助類和函數，以及為了COM而生的ATL；從本質上看，這些類庫都是把COM規范中必須實現的，Windows平臺本身沒有提供，具體設計和開發人員實際實施時會重復實現的，同時又非常容易出錯的那部分功能，集中到了這些類庫里統一實現，讓具體設計和開發人員以代碼重用的形式來實現COM規范；
當然人們也意識到了COM這樣的一些問題，特別是具體實現時設計和開發人員必須要關注幾乎所有的二進制細節，于是.net就誕生了，把這些規范的許多復雜性都封裝在了虛擬機里面，把這些目標功能（跨邊界、透明性等等）通過一致而又平滑的平臺接口和自描述的meta data，以一種讓設計和開發人員更易接受的風格開放了出來；
COM的影響是非常廣大的，比如XPCOM ，Firefox上的一種插件技術標準，就是根據COM的思想和原則制定的；許多評論說，Firefox的成功是因為它插件是如此的成功，這也算是COM本身所意料不到的貢獻之一。
在.net的平臺上，即使是.net CLR/SSCLI的具體實現也大量運用了COM的思想和機制，可以說.net就是搭建在COM二進制組件平臺之上的虛擬機托管平臺。
最后，.net開始時的內部編號是COM 2.0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*) 關于“名詞太多”
這是要實現可以跨進程和機器邊界，跨異構平臺（當然必須實現了COM所規定的基礎服務），透明化具體對象類型及對象生命周期，便于統一部署和版本管理的組件技術，所必須付出的代價。
COM規范已把要達致這些目標的系統，所必須提供的接口和特性抽象了出來，只不過為了表達這些抽象的概念而新造的術語名詞有些陌生和突兀；如果讓遇到相似問題的每一個設計和開發人員都自己來做抽象，未必會生成更好的方案；
舉個例子，apartment，套間，就是為了抽象傳統OS中進程和線程的實現而新造的術語名詞和概念；任何人要抽象這樣的一些概念，不新造術語，是非常困難的，對比.net，后者用了CLR虛擬機來封裝了大多數的實現細節，并用讓人更容易接受的風格來開放接口，可事實上仍然新造了一些名詞和概念，如類似范疇的AppDomain；
*) 關于“基于ATL的實現比較難懂”
ATL主要使用了template技術，COM接口智能指針，用靜態轉換來模擬動態綁定，等等，實際并不是很復雜，只能算c++實現機制的中等難度，主要涉及Modern C++ design一書中一些相關設計理念的運用。對比Boost中某些庫的實現，ATL很人道了。
*) 關于“這并不是COM本身復雜，而是C++已經落后于時代了”
首先COM的規范的確是復雜的，為啥？第一點已經說了，就是為了要抽象出跨邊界和對象透明的組件技術；.net表象上看比較“簡單容易”，風格親近設計和開發人員，實際上復雜事務和實現細節都被劃分到CLR那個層面上去實現了；去看一下CLR的開源實現SSCLI，你會發現，整個虛擬機平臺的實現，大量運用了COM的思想和機制，就是一個巨型系統平臺級的COM server；
其次，COM規范本身是獨立于實現語言的，只要構建出的組件符合規范制定的二進制兼容，系統就可以運作，這和C++是否落后時代沒有關系。如果開發人員認為，.net才夠先進，也完全可以用.net中的托管語言，如C#來實現COM組件；
最后，每種語言都有其適用的范圍，現在可以這么說“如果有一個全新的項目需求，要達致跨邊界和對象透明組件，并且沒有太過嚴苛的性能需求，那么.net平臺及其上的托管語言來實現，比用C++及相關輔助類庫來以COM組件形式來實現，要更合適，也更快速便捷和節省預算。”但是，在這個判斷上我們加了很多嚴格的約束，一旦需求變更，特別是項目的非功能性需求，要求高性能運算或者更順暢的與legacy的native系統相互，那么“使用native語言來實現性能關鍵以及legacy交互功能，通過COM封裝，再由COMInterop交.net托管應用調用”可能是更現實的方案。C++是一門活的語言，不斷發展的語言，即使在最新的托管時代里，C#成為標準主流，但C++/CLI仍然是托管語言里功能最完整的語言。