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