這是那篇C++0X的正文。太長,，先寫上半部分發(fā)了。

Function/bind可以是一個(gè)很簡單的話題,，因?yàn)樗鋵?shí)不過就是一個(gè)泛型的函數(shù)指針,。但是如果那么來談,，就沒意思了,，也犯不上寫這篇東西,。在我看來，這個(gè)事情要講的話,，就應(yīng)該講透,，講到回調(diào)（callback）,、代理（delegate）,、信號(hào)（signal）和消息傳遞（messaging）的層面,，因?yàn)樗_實(shí)是太重要了,。這個(gè)話題不但與面向?qū)ο蟮暮诵乃枷朊芮邢嚓P(guān),，而且是面向?qū)ο髢纱罅髋芍g交鋒的中心,。圍繞這個(gè)問題的思考和爭論,，幾乎把20年來所有主流的編程平臺(tái)和編程語言都攪進(jìn)來了,。所以，如果詳盡鋪陳,，這個(gè)話題直接可以寫一本書。

寫書我當(dāng)然沒那個(gè)水平,，但這個(gè)題目確實(shí)一直想動(dòng)一動(dòng),。然而這個(gè)主題實(shí)在太大，我實(shí)在沒有精力把它完整的寫下來,；這個(gè)主題也很深,，特別是涉及到并發(fā)環(huán)境有關(guān)的話題,，我的理解還非常膚淺,，總覺得我認(rèn)識(shí)的很多高手都比我更有資格寫這個(gè)話題,。所以猶豫了很久,，要不要現(xiàn)在寫,，該怎么寫,。最后我覺得，確實(shí)不能把一篇博客文章寫成一本20年面向?qū)ο蠹夹g(shù)史記,，所以決定保留大的架構(gòu),，但是對(duì)其中具體的技術(shù)細(xì)節(jié)點(diǎn)到為止。我不會(huì)去詳細(xì)地列舉代碼,，分析對(duì)象的內(nèi)存布局,，畫示意圖,，但是會(huì)把最重要的結(jié)論和觀點(diǎn)寫下來，說得好聽一點(diǎn)是提綱挈領(lǐng),，說的不好聽就是語焉不詳,。但無論如何，我想這樣一篇東西,，一是談?wù)勎覍?duì)這個(gè)事情的看法,，二是“拋磚引玉”，引來高手的關(guān)注,，引出更深刻和完整的敘述,。

下面開始。

0. 程序設(shè)計(jì)有一個(gè)范式（paradigm）問題,。所謂范式，就是組織程序的基本思想,，而這個(gè)基本思想，反映了程序設(shè)計(jì)者對(duì)程序的一個(gè)基本的哲學(xué)觀,，也就是說,，他認(rèn)為程序的本質(zhì)是什么，他認(rèn)為一個(gè)大的程序是由什么組成的,。而這，又跟他對(duì)于現(xiàn)實(shí)世界的看法有關(guān),。顯然,，這樣的看法不可能有很多種。編程作為一門行業(yè),，獨(dú)立存在快60年了,，但是所出現(xiàn)的范式不過三種——過程范式,、函數(shù)范式,、對(duì)象范式。其中函數(shù)范式與現(xiàn)實(shí)世界差距比較大,，在這里不討論,。而過程范式和對(duì)象范式可以視為對(duì)程序本質(zhì)的兩種根本不同的看法，而且能夠分別在現(xiàn)實(shí)世界中找到相應(yīng)的映射,。

• 過程范式認(rèn)為，程序是由一個(gè)又一個(gè)過程經(jīng)過順序,、選擇和循環(huán)的結(jié)構(gòu)組合而成。反映在現(xiàn)實(shí)世界,，過程范式體現(xiàn)了勞動(dòng)分工之前“全能人”的工作特點(diǎn)——所有的事情都能干,，所有的資源都是我的，只不過得具體的事情得一步步地來做,。
• 對(duì)象范式則反映了勞動(dòng)分工之后的團(tuán)隊(duì)協(xié)作的工作特點(diǎn)——每個(gè)人各有所長,，各司其職,，有各自的私有資源，工件和信息在人們之間彼此傳遞,，最后完成工作,。因此，對(duì)象范式也就形成了自己對(duì)程序的看法——程序是由一組對(duì)象組成,，這些對(duì)象各有所能,，通過消息傳遞實(shí)現(xiàn)協(xié)作。

對(duì)象范式與過程范式相比,，有三個(gè)突出的優(yōu)勢,，第一,，由于實(shí)現(xiàn)了邏輯上的分工，降低了大規(guī)模程序的開發(fā)難度,。第二,，靈活性更好——若干對(duì)象在一起，可以靈活組合,，可以以不同的方式協(xié)作,，完成不同的任務(wù)，也可以靈活的替換和升級(jí),。第三,，對(duì)象范式更加適應(yīng)圖形化、網(wǎng)絡(luò)化,、消息驅(qū)動(dòng)的現(xiàn)代計(jì)算環(huán)境,。

所以，較之于過程范式,，對(duì)象范式,，或者說“面向?qū)ο蟆保_實(shí)是更具優(yōu)勢的編程范式,。最近看到一些文章抨擊面向?qū)ο?，說面向?qū)ο笫呛叮艺J(rèn)為要具體分析,。對(duì)面向?qū)ο蟮囊徊糠峙u(píng),，是沖著主流的“面向?qū)ο蟆闭Z言去的，這確實(shí)是有道理的,，我在下面也會(huì)談到,，而且會(huì)罵得更狠。而另一個(gè)批評(píng)的聲音,，主要而來自STL之父Alex Stepanov,，他說的當(dāng)然有他的道理，不過要知道該牛人是前蘇聯(lián)莫斯科國立羅蒙諾索夫大學(xué)數(shù)學(xué)系博士,，你只要翻翻前蘇聯(lián)的大學(xué)數(shù)學(xué)教材就知道了,，能夠在莫大拿到數(shù)學(xué)博士的，根本就是披著人皮的外星高等智慧,。而我們編寫地球上的程序,，可能還是應(yīng)該以地球人的觀點(diǎn)為主。

1. 重復(fù)一遍對(duì)象范式的兩個(gè)基本觀念：

• 程序是由對(duì)象組成的,；
• 對(duì)象之間互相發(fā)送消息,，協(xié)作完成任務(wù)；

請(qǐng)注意,，這兩個(gè)觀念與后來我們熟知的面向?qū)ο笕亍胺庋b,、繼承,、多態(tài)”根本不在一個(gè)層面上，倒是與再后來的“組件,、接口”神合,。

2. 世界上第一個(gè)面向?qū)ο笳Z言是Simula-67，第二個(gè)面向?qū)ο笳Z言是Smalltalk-71,。Smalltalk受到了Simula-67的啟發(fā),，基本出發(fā)點(diǎn)相同，但也有重大的不同,。先說相同之處，Simula和Smalltalk都秉承上述對(duì)象范式的兩個(gè)基本觀念,，為了方便對(duì)象的構(gòu)造,，也都引入了類、繼承等概念,。也就是說,，類、繼承這些機(jī)制是為了實(shí)現(xiàn)對(duì)象范式原則而構(gòu)造出來的第二位的,、工具性的機(jī)制,，那么為什么后來這些第二位的東西篡了主位，后面我會(huì)再來分析,。而Simula和Smalltalk最重大的不同,，就是Simula用方法調(diào)用的方式向?qū)ο蟀l(fā)送消息，而Smalltalk構(gòu)造了更靈活和更純粹的消息發(fā)送機(jī)制,。

具體的說,，向一個(gè)Simula對(duì)象中發(fā)送消息，就是調(diào)用這個(gè)對(duì)象的一個(gè)方法,，或者稱成員函數(shù),。那么你怎么知道能夠在這個(gè)對(duì)象上調(diào)用這個(gè)成員函數(shù)呢？或者說,，你怎么知道能夠向這個(gè)對(duì)象發(fā)送某個(gè)消息呢,？這就要求你必須確保這個(gè)對(duì)象具有合適的類型，也就是說,，你得先知道哦這個(gè)對(duì)象是什么,，才能向它發(fā)消息。而消息的實(shí)現(xiàn)方式被直接處理為成員函數(shù)調(diào)用,，或虛函數(shù)調(diào)用,。

而Smalltalk在這一點(diǎn)上做了一個(gè)歷史性的跨越，它實(shí)現(xiàn)了一個(gè)與目標(biāo)對(duì)象無關(guān)的消息發(fā)送機(jī)制,，不管那個(gè)對(duì)象是誰,，也不管它是不是能正確的處理一個(gè)消息,，作為發(fā)送消息的對(duì)象來說，可以毫無顧忌地抓住一個(gè)對(duì)象就發(fā)消息過去,。接到消息的對(duì)象,，要嘗試?yán)斫膺@個(gè)消息，并最后調(diào)用自己的過程來處理消息,。如果這個(gè)消息能被處理,，那個(gè)對(duì)象自然會(huì)處理好，如果不能被處理,，Smalltalk系統(tǒng)會(huì)向消息的發(fā)送者回傳一個(gè)doesNotUnderstand消息,，予以通知。對(duì)象不用關(guān)心消息是如何傳遞給另一個(gè)對(duì)象的,，傳遞過程被分離出來（而不是像Simula那樣明確地被以成員函數(shù)調(diào)用的方式實(shí)現(xiàn)）,，可以是在內(nèi)存中復(fù)制，也可以是進(jìn)程間通訊,。到了Smalltalk-80時(shí),，消息傳遞甚至可以跨越網(wǎng)絡(luò)。

為了方便后面的討論,，不妨把源自Simula的消息機(jī)制稱為“靜態(tài)消息機(jī)制”,，把源自Smalltalk的消息機(jī)制稱為“動(dòng)態(tài)消息機(jī)制”。

Simula與Smalltalk之間對(duì)于消息機(jī)制的不同選擇,，主要是因?yàn)閮烧哂谟猛?。前者是用于仿真程序開發(fā)，而后者用于圖形界面環(huán)境構(gòu)建,，看上去各自合情合理,。然而，就是這么一點(diǎn)簡單的區(qū)別,，卻造成了巨大的歷史后果,。

3. 到了1980年代，C++出現(xiàn)了,。Bjarne Stroustrup在博士期間深入研究過Simula,，非常欣賞其思想，于是就在C語言語法的基礎(chǔ)之上,，幾乎把Simula的思想照搬過來,，形成了最初的C++。C++問世以之初,，主要用于解決規(guī)模稍大的傳統(tǒng)類型的編程問題,，迅速取得了巨大的成功，也證明了對(duì)象范式本身所具有的威力,。

大約在同期,，Brad Cox根據(jù)Smalltalk的思想設(shè)計(jì)了Objective-C,，可是由于其語法怪異，沒有流行起來,。只有Steve Jobs這種具有禪宗美學(xué)鑒賞力的世外高人,，把它奉為瑰寶，與1988年連鍋把Objective-C的團(tuán)隊(duì)和產(chǎn)品一口氣買了下來,。

4. 就在同一時(shí)期,，GUI成為熱門。雖然GUI的本質(zhì)是對(duì)象范型的,，但是當(dāng)時(shí)（1980年代中期）的面向?qū)ο笳Z言,，包括C++語言，還遠(yuǎn)不成熟,，因此最初的GUI系統(tǒng)無一例外是使用C和匯編語言開發(fā)的,。或者說,，最初的GUI開發(fā)者硬是用抽象級(jí)別更低的語言構(gòu)造了一個(gè)面向?qū)ο笙到y(tǒng)。熟悉Win32 SDK開發(fā)的人,，應(yīng)該知道我在說什么,。

5. 當(dāng)時(shí)很多人以為，如果C++更成熟些,，直接用C++來構(gòu)造Windows系統(tǒng)會(huì)大大地容易,。也有人覺得，盡管Windows系統(tǒng)本身使用C寫的,，但是其面向?qū)ο蟮谋举|(zhì)與C++更契合,，所以在其基礎(chǔ)上包裝一個(gè)C++的GUI framework一定是輕而易舉?？墒且粍?dòng)手人們就發(fā)現(xiàn),，完全不是那么回事。用C++開發(fā)Windows框架難得要死,。為什么呢,？主要就是Windows系統(tǒng)中的消息機(jī)制實(shí)際上是動(dòng)態(tài)的，與C++的靜態(tài)消息機(jī)制根本配合不到一起去,。在Windows里,，你可以向任何一個(gè)窗口發(fā)送消息，這個(gè)窗口自己會(huì)在自己的wndproc里來處理這個(gè)消息,，如果它處理不了,，就交給default window/dialog proc去處理。而在C++里,，你要向一個(gè)窗口發(fā)消息,，就得確保這個(gè)窗口能處理這個(gè)消息,，或者說，具有合適的類型,。這樣一來的話,，就會(huì)導(dǎo)致一個(gè)錯(cuò)綜復(fù)雜的窗口類層次結(jié)構(gòu)，無法實(shí)現(xiàn),。而如果你要讓所有的窗口類都能處理所有可能的消息,，且不論這樣在邏輯上就行不通（用戶定義的消息怎么處理？）,，單在實(shí)現(xiàn)上就不可接受——為一個(gè)小小的不同就得創(chuàng)造一個(gè)新的窗口類,，每一個(gè)小小的窗口類都要背上一個(gè)多達(dá)數(shù)百項(xiàng)的v-table，而其中可能99%的項(xiàng)都是浪費(fèi),，不要說在當(dāng)時(shí),，就是在今天，內(nèi)存數(shù)量非常豐富的時(shí)候,，如果每一個(gè)GUI程序都這么搞,，用戶也吃不消。

6. 實(shí)際上C++的靜態(tài)消息機(jī)制還引起了更深嚴(yán)重的問題——扭曲了人們對(duì)面向?qū)ο蟮睦斫?。既然必須要先知道?duì)象的類型,，才能向?qū)ο蟀l(fā)消息，那么“類”這個(gè)概念就特別重要了,，而對(duì)象只不過是類這個(gè)模子里造出來的東西,，反而不重要。漸漸的,，“面向?qū)ο缶幊獭弊兂闪恕懊嫦蝾惥幊獭?，“面向類編程”變成了“?gòu)造類繼承樹”。放在眼前的鮮活的對(duì)象活動(dòng)不重要了,，反而是其背后的靜態(tài)類型系統(tǒng)成為關(guān)鍵,。“封裝,、繼承”這些第二等的特性,，喧賓奪主，儼然成了面向?qū)ο蟮囊?。每個(gè)程序員似乎都要先成為領(lǐng)域?qū)＜?，然后成為領(lǐng)域分類學(xué)專家，然后構(gòu)造一個(gè)完整的繼承樹,，然后才能new出對(duì)象,，讓程序跑起來。正是因?yàn)檫@個(gè)過程太漫長，太困難,，再加上C++本身的復(fù)雜度就很大,，所以C++出現(xiàn)這么多年，真正堪稱經(jīng)典的面向?qū)ο箢悗旌涂蚣?，幾乎屈指可?shù),。很多流行的庫，比如MFC,、iostream,，都暴露出不少問題。一般程序員總覺得是自己的水平不夠,，于是下更大功夫去練劍,。殊不知根本上是方向錯(cuò)了，脫離了對(duì)象范式的本質(zhì),，企圖用靜態(tài)分類法來對(duì)現(xiàn)實(shí)世界建模,，去刻畫變化萬千的動(dòng)態(tài)世界。這么難的事,，你水平再高也很難做好,。

可以從一個(gè)具體的例子來理解這個(gè)道理，比如在一個(gè)GUI系統(tǒng)里,，一個(gè) Push Button 的設(shè)計(jì)問題,。事實(shí)上在一個(gè)實(shí)際的程序里，一個(gè) push button 到底“是不是”一個(gè) button,，進(jìn)而是不是一個(gè) window/widget，并不重要,，本質(zhì)上我根本不關(guān)心它是什么,，它從屬于哪一個(gè)類，在繼承樹里處于什么位置,，只要那里有這么一個(gè)東西,，我可以點(diǎn)它，點(diǎn)完了可以發(fā)生相應(yīng)的效果,，就可以了,。可是Simula –> C++ 所鼓勵(lì)的面向?qū)ο笤O(shè)計(jì)風(fēng)格,，非要上來就想清楚,，a Push Button is-a Button, a Button is-a Command-Target Control, a Command-Target Control is-a Control, a Control is-a Window. 把這一圈都想透徹之后，才能 new 一個(gè) Push Button,，然后才能讓它工作,。這就形而上學(xué)了，這就脫離實(shí)際了,。所以很難做好,。你看到 MFC 的類繼承樹,，覺得設(shè)計(jì)者太牛了，能把這些層次概念都想清楚,，自己的水平還不夠,，還得修煉。實(shí)際上呢,，這個(gè)設(shè)計(jì)是經(jīng)過數(shù)不清的失敗和錢磨出來,、砸出來的，MFC的前身 Afx 不是就失敗了嗎,？1995年還有一個(gè)叫做 Taligent 的大項(xiàng)目,，召集了包括 Eric Gamma 在內(nèi)的一大堆牛人，要用C++做一個(gè)一統(tǒng)天下的application framework,，最后也以慘敗告終,，連公司都倒閉了，CEO車禍身亡,，牛人們悉數(shù)遣散,。附帶說一下，這個(gè)Taligent項(xiàng)目是為了跟NextSTEP和Microsoft Cairo競爭,，前者用Objective-C編寫,，后來發(fā)展為Cocoa，后者用傳統(tǒng)的Win32 + COM作為基礎(chǔ)架構(gòu),，后來發(fā)展為Windows NT,。而Objective-C和COM，恰恰就在動(dòng)態(tài)消息分派方面,，與C++迥然不同,。后面還會(huì)談到。

客觀地說,，“面向類的設(shè)計(jì)”并不是沒有意義,。來源于實(shí)踐又高于實(shí)踐的抽象和概念，往往能更有力地把握住現(xiàn)實(shí)世界的本質(zhì),，比如MVC架構(gòu),，就是這樣的有力的抽象。但是這種抽象,，應(yīng)該是來源于長期最佳實(shí)踐的總結(jié)和提高,，而不是面對(duì)問題時(shí)主要的解決思路。過于強(qiáng)調(diào)這種抽象,，無異于假定程序員各個(gè)都是哲學(xué)家,，具有對(duì)現(xiàn)實(shí)世界準(zhǔn)確而深刻的抽象能力，當(dāng)然是不符合實(shí)際情況的。結(jié)果呢,，剛學(xué)習(xí)面向?qū)ο鬀]幾天的程序員,，對(duì)眼前鮮活的對(duì)象世界視而不見，一個(gè)個(gè)都煞有介事地去搞哲學(xué)冥想,，企圖越過現(xiàn)實(shí)世界,，去抽象出其背后本質(zhì)，當(dāng)然敗得很慘,。

其實(shí)C++問世之后不久,，這個(gè)問題就暴露出來了。第一個(gè)C++編譯器 Cfront 1.0 是單繼承,，而到了 Cfront 2.0,，加入了多繼承。為什么,？就是因?yàn)槭褂弥腥藗儼l(fā)現(xiàn)邏輯上似乎完美的靜態(tài)單繼承關(guān)系,，碰到復(fù)雜靈活的現(xiàn)實(shí)世界，就破綻百出——蝙蝠是鳥也是獸,，水上飛機(jī)能飛也能游,，它們?cè)撊绾螝w類呢？本來這應(yīng)該促使大家反思繼承這個(gè)機(jī)制本身,，但是那個(gè)時(shí)候全世界陷入繼承狂熱,，于是就開始給繼承打補(bǔ)丁，加入多繼承,，進(jìn)而加入虛繼承,，。到了虛繼承,，明眼人一看便知,，這只是一個(gè)語法補(bǔ)丁，是為了逃避職責(zé)而制造的一塊無用的遮羞布,，它已經(jīng)完全已經(jīng)脫離實(shí)踐了——有誰在事前能夠判斷是否應(yīng)該對(duì)基類進(jìn)行虛繼承呢？

到了1990年代中期,，問題已經(jīng)十分明顯,。UML中有一個(gè)對(duì)象活動(dòng)圖，其描述的就是運(yùn)行時(shí)對(duì)象之間相互傳遞消息的模型,。1994年Robert C. Martin在《Object-Oriented C++ Design Using Booch Method》中,，曾建議面向?qū)ο笤O(shè)計(jì)從對(duì)象活動(dòng)圖入手，而不是從類圖入手,。而1995年出版的經(jīng)典作品《Design Patterns》中,，建議優(yōu)先考慮組合而不是繼承，這也是盡人皆知的事情。這些跡象表明,，在那個(gè)時(shí)候,，面向?qū)ο笊鐓^(qū)里的思想領(lǐng)袖們，已經(jīng)意識(shí)到“面向類的設(shè)計(jì)”并不好用,。只可惜他們的革命精神還不夠,。

7. 你可能要問，Java 和.NET也是用繼承關(guān)系組織類庫,，并進(jìn)行設(shè)計(jì)的啊,，怎么那么成功呢？這里有三點(diǎn)應(yīng)該注意,。第一,，C++的難不僅僅在于其靜態(tài)結(jié)構(gòu)體系，還有很多源于語言設(shè)計(jì)上的包袱,，比如對(duì)C的兼容,，比如沒有垃圾收集機(jī)制，比如對(duì)效率的強(qiáng)調(diào),，等等,。一旦把這些包袱丟掉，設(shè)計(jì)的難度確實(shí)可以大大下降,。第二,，Java和.NET的核心類庫是在C++十幾年成功和失敗的經(jīng)驗(yàn)教訓(xùn)基礎(chǔ)之上，結(jié)合COM體系優(yōu)點(diǎn)設(shè)計(jì)實(shí)現(xiàn)的,，自然要好上一大塊,。事實(shí)上，在Java和.NET核心類庫的設(shè)計(jì)中很多地方,，體現(xiàn)的是基于接口的設(shè)計(jì),，和真正的基于對(duì)象的設(shè)計(jì)。有了這兩個(gè)主角站臺(tái),，“面向類的設(shè)計(jì)”不能喧賓奪主,，也能發(fā)揮一些好的作用。第三,，如后文指出,，Java和.NET中分別對(duì)C++最大的問題——缺少對(duì)象級(jí)別的delegate機(jī)制做出了自己的回應(yīng)，這就大大彌補(bǔ)了原來的問題,。

盡管如此,，Java還是沾染上了“面向類設(shè)計(jì)”的癌癥，基礎(chǔ)類庫里就有很多架床疊屋的設(shè)計(jì),，而J2EE/Java EE當(dāng)中,，這種形而上學(xué)的設(shè)計(jì)也很普遍,，所以也引發(fā)了好幾次輕量化的運(yùn)動(dòng)。這方面我并不是太懂,，可能需要真正的Java高手出來現(xiàn)身說法,。我對(duì)Java的看法以前就講過——平臺(tái)和語言核心非常好，但風(fēng)氣不好,，崇尚華麗繁復(fù)的設(shè)計(jì),，裝牛逼的人太多。

至于.NET,，我聽陳榕介紹過,，在設(shè)計(jì).NET的時(shí)候，微軟內(nèi)部對(duì)于是否允許繼承爆發(fā)了非常激烈的爭論,。很多資深高人都強(qiáng)烈反對(duì)繼承,。至于最后引入繼承，很大程度上是營銷需要壓倒了技術(shù)理性,。盡管如此,，由于有COM的基礎(chǔ)，又實(shí)現(xiàn)了非常徹底的delegate,，所以 .NET 的設(shè)計(jì)水平還是很高的,。它的主要問題不在這，在于太急于求勝,，更新速度太快,，基礎(chǔ)不牢。當(dāng)然,，根本問題還是微軟沒有能夠在Web和Mobile領(lǐng)域里占到多大的優(yōu)勢,，也就使得.NET沒有用武之地。

8. COM,。COM的要義是,，軟件是由COM Components組成，components之間彼此通過接口相互通訊,。這是否讓你回想起本文開篇所提出的對(duì)象范型的兩個(gè)基本原則,？有趣的是，在COM的術(shù)語里,，“COM Component ” 與“object ”通假,，這就使COM的心思昭然若揭了。Don Box在Essential COM里開篇就說,，COM是更好的C++，事實(shí)上就是告訴大家,，形而上學(xué)的“面向類設(shè)計(jì)”不好使,，還是回到對(duì)象吧,。

用COM開發(fā)的時(shí)候，一個(gè)組件“是什么”不重要,，它具有什么接口,，也就是說，能夠?qū)λl(fā)什么消息,，才是重要的,。你可以用IUnknown::QueryInterface問組件能對(duì)哪一組消息作出反應(yīng)。向組件分派消息也不一定要被綁定在方法調(diào)用上,，如果實(shí)現(xiàn)了 IDispatch,，還可以實(shí)現(xiàn)“自動(dòng)化”調(diào)用，也就是COM術(shù)語里的 Automation,，而通過 列集（mashal）,，可以跨進(jìn)程、跨網(wǎng)絡(luò)向另一組件發(fā)送消息,，通過 moniker,，可以在分布式系統(tǒng)里定位和發(fā)現(xiàn)組件。如果你抱著“對(duì)象——消息”的觀念去看COM的設(shè)計(jì),，就會(huì)意識(shí)到,，整個(gè)COM體系就是用規(guī)范如何做對(duì)象，如何發(fā)消息的,?；蛘吒卑滓稽c(diǎn)，COM就是用C/C++硬是模擬出一個(gè)Smalltalk,。而且COM的概念世界里沒有繼承,，就其純潔性而言，比Smalltalk還Smalltalk,。在對(duì)象泛型上,，COM達(dá)到了一個(gè)高峰，領(lǐng)先于那個(gè)時(shí)代,，甚至于比它的繼任.NET還要純潔,。

COM的主要問題是它的學(xué)習(xí)難度和安全問題，而且,，它過于追求純潔性,，完全放棄了“面向類設(shè)計(jì)” 的機(jī)制，顯得有點(diǎn)過,。

9. 好像有點(diǎn)扯遠(yuǎn)了,，其實(shí)還是在說正事。上面說到由于C++的靜態(tài)消息機(jī)制,，導(dǎo)致了形而上學(xué)的“面向類的設(shè)計(jì)”,，禍害無窮,。但實(shí)際上，C++是有一個(gè)補(bǔ)救機(jī)會(huì)的,，那就是實(shí)現(xiàn)對(duì)象級(jí)別的delegate機(jī)制,。學(xué)過.NET的人，一聽delegate這個(gè)詞就知道是什么意思,，但Java里沒有對(duì)應(yīng)機(jī)制,。在C++的術(shù)語體系里，所謂對(duì)象級(jí)別delegate,，就是一個(gè)對(duì)象回調(diào)機(jī)制,。通過delegate，一個(gè)對(duì)象A可以把一個(gè)特定工作,，比如處理用戶的鼠標(biāo)事件,，委托給另一個(gè)對(duì)象B的一個(gè)方法來完成。A不必知道B的名字,，也不用知道它的類型,，甚至都不需要知道B的存在，只要求B對(duì)象具有一個(gè)簽名正確的方法,，就可以通過delegate把工作交給B的這個(gè)方法來執(zhí)行,。在C語言里，這個(gè)機(jī)制是通過函數(shù)指針實(shí)現(xiàn)的,，所以很自然的,，在C++里，我們希望通過指向成員函數(shù)的指針來解決類似問題,。

然而就在這個(gè)問題上,，C++讓人扼腕痛惜。