此文只是雜亂的記錄一點(diǎn)點(diǎn)對(duì)于面向?qū)ο蟮膫€(gè)人看法，有些觀點(diǎn)也并非原創(chuàng)。沒(méi)什么系統(tǒng)性可言，雖然筆者稍作整理，但始終還是顯得很散亂，只是一些片段的堆積。

由于涉及的題目過(guò)于龐大，反而不知道如何下筆。先羅列一下問(wèn)題，之間沒(méi)有嚴(yán)格的先后之分，純粹就是筆者想到哪里，就寫到哪里。也不一定就會(huì)解答。繼承的本質(zhì)是什么？為什么一定要有接口？c++多繼承為何飽受非議，真的就一無(wú)是處？為何筆者就反感go接口，反正go獨(dú)有的一切，筆者都是下意識(shí)的排斥？功能繁雜的Com，結(jié)合C++的自身特點(diǎn)，能否改頭換面？ ……

在原教旨眼里，面向?qū)ο蟮慕塘x就是“對(duì)象+消息發(fā)送”，整個(gè)程序由對(duì)象組成，而對(duì)象之間的就僅僅只通過(guò)發(fā)送消息響應(yīng)消息來(lái)交互，程序的功能都是在對(duì)象與對(duì)象的來(lái)回消息發(fā)送中完成，用現(xiàn)實(shí)事情類比，人類就是一個(gè)個(gè)活生生的對(duì)象，人類通過(guò)消息的往來(lái)，比如語(yǔ)音、文字、廣播等，有人制造新聞，有人接受到這些消息后，各自反應(yīng)，最后完成一切社會(huì)活動(dòng)。好像說(shuō)得有點(diǎn)抽象，展開(kāi)來(lái)說(shuō)，其實(shí)就是，消息的發(fā)送者，原則上不需要事先了解目標(biāo)對(duì)象的任何背景資料，甚至他明知道對(duì)方不鳥消息，比如說(shuō)，明明對(duì)方就是一個(gè)乞丐，但是并不妨礙你向他借500萬(wàn)人民幣，反正，消息就是這樣發(fā)送出去的。然后，對(duì)象接受到消息之后，就各自反應(yīng)，比如說(shuō)有人真的借錢給你；有人哭窮；有人嘀咕你到處借錢，無(wú)恥；……，各式各樣，不一而足。

聽(tīng)起來(lái)好像人類社會(huì)活動(dòng)就是消息的往來(lái)下推動(dòng)，艱難的前進(jìn)，但是，這能拿來(lái)搬磚嗎？可以的，真的可以！即便是C語(yǔ)言，都可以來(lái)搞消息發(fā)送這種高大上的事情，就好像win32那樣子，通過(guò)SendMessage函數(shù)給窗口發(fā)送消息，其簽名如下：

LRESULT SendMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);

好像參數(shù)有點(diǎn)多。說(shuō)白了，消息發(fā)送就相當(dāng)于成員函數(shù)函數(shù)調(diào)用的一個(gè)新馬甲，換了一種說(shuō)法而已。成員函數(shù)調(diào)用，形式是這樣子，obj.fn(param1, param2, …)，涉及到對(duì)象，函數(shù)名字，還有參數(shù)，可能參數(shù)數(shù)量不止一個(gè)，參數(shù)類型也各不一樣，這些都沒(méi)關(guān)系。hWnd為窗口，也即是對(duì)象；Msg為函數(shù)名稱，現(xiàn)在用正整型編號(hào)來(lái)代表，有些消息發(fā)送系統(tǒng)用原子，qt好像是用字符串（性能堪憂啊）；wParam，lParam可以看成void*類型，也即是函數(shù)的參數(shù)，用這兩個(gè)值封裝所有的參數(shù)。天真，天下函數(shù)參數(shù)類型成千上萬(wàn)，參數(shù)數(shù)目或0個(gè)、或1個(gè)、或三五個(gè)、或七八個(gè)，就wParam，lParam這兩個(gè)弱雞，就能封裝得過(guò)來(lái)？可以的，通過(guò)強(qiáng)制類型轉(zhuǎn)換，就可以讓void*的值保存char、int、float等值，又或者是將參數(shù)打包為結(jié)構(gòu)體，這樣子，就可以應(yīng)付千千萬(wàn)萬(wàn)的函數(shù)參數(shù)要求，這樣子，不要說(shuō)，有兩個(gè)wParam，lParam來(lái)傳遞參數(shù)，就算是只有一個(gè)，也都可以應(yīng)付千千萬(wàn)萬(wàn)的函數(shù)要求。

那么，如何響應(yīng)消息？可以參考win32的原生api開(kāi)發(fā)，這里就不展開(kāi)了。原理就是，每個(gè)對(duì)象都有一個(gè)函數(shù)指針，那個(gè)函數(shù)把全部的成員函數(shù)都?jí)嚎s在一個(gè)龐大的switch語(yǔ)句里面，每個(gè)消息編號(hào)case分支，就代表一個(gè)成員函數(shù)，顯然，這個(gè)分支，要先將wParam，lParam里面在還原成對(duì)應(yīng)參數(shù)的實(shí)際情況，然后再執(zhí)行相應(yīng)操作。

SendMessage顯然抹去了所有窗口的具體類型信息，甭管你是按鈕、漂亮按鈕、菜單、編輯框、……，全部一律都退化成窗口對(duì)象。要往編輯框里面添加文字，就給它發(fā)送添加文字的消息，wParam，lParam就帶著要添加的文本和長(zhǎng)度。而不是調(diào)用編輯框的添加文字的成員函數(shù)來(lái)做這個(gè)事情，最明顯的事情，就是也可以給按鈕窗口也發(fā)送添加文本的消息，雖然按鈕窗口對(duì)此消息的反應(yīng)是啥也不做。令人驚訝的是，你可以子類化一個(gè)按鈕窗口，讓它對(duì)添加文本的消息做出反應(yīng)，這完全是可以的。

顯然，原教旨的面向?qū)ο蠼塘x，的而且確，靈活，解耦徹底，不同類型對(duì)象之間的耦合關(guān)系一律不復(fù)存在，之間只有消息的往來(lái)。隨心所欲的發(fā)送消息（胡亂調(diào)用成員函數(shù)），自由自在的反應(yīng)消息（一切全無(wú)契約可言），不理睬，或者這一刻不理睬下一刻又動(dòng)了，或者這一刻動(dòng)了下一刻又拒絕反應(yīng)。甚至，消息還可以保存，排隊(duì)，求反，疊加什么的，也即是消息已經(jīng)是一種抽象數(shù)據(jù)類型了，支持多種運(yùn)算。相比于不知所謂的基于類的靜態(tài)面向?qū)ο螅ɡ^承封裝多態(tài)），簡(jiǎn)直不可同日而語(yǔ)，太多的約束，呆板的語(yǔ)法，深入的哲學(xué)思考，架床疊屋的類型關(guān)系，也好意思學(xué)人家叫面向?qū)ο蟆?/span>

當(dāng)然，對(duì)象+消息發(fā)送這種機(jī)制，付出的代價(jià)也是很巨大的，基本上，函數(shù)調(diào)用的靜態(tài)類型檢查不服存在，所有問(wèn)題都要到運(yùn)行時(shí)才能發(fā)現(xiàn)。并且，消息發(fā)送的語(yǔ)法也很不直觀，必須各種類型轉(zhuǎn)換，而響應(yīng)消息時(shí)又必須轉(zhuǎn)換回去。此外，為函數(shù)定義消息編號(hào)，也很惡心。不過(guò)，這些在動(dòng)態(tài)語(yǔ)言里面都不是問(wèn)題，反正，動(dòng)態(tài)語(yǔ)言里面沒(méi)有靜態(tài)類型約束。另外，筆者用template、全局變量、宏等奇技淫巧，在c++里面，已經(jīng)實(shí)現(xiàn)了類型安全的消息發(fā)送框架，比如，Send(obj, kAppendText, U8String(“hello”))，而對(duì)象實(shí)現(xiàn)對(duì)消息的響應(yīng)，直接也是成員函數(shù)的形式，并且還是非侵入式的，也即是說(shuō)，在main函數(shù)之前，可以隨時(shí)在任意地方給對(duì)象添加新的消息反射，所有參數(shù)上類型轉(zhuǎn)換以及返回值上的類型轉(zhuǎn)換，全部都不需要了。 但即便是這樣，也不贊成原教旨的面向?qū)ο蟮教幏簽E。原因是，用它寫出來(lái)的程序，類型層次很不清晰，相比于架構(gòu)良好的類形式的面向?qū)ο蟪绦颍勺x性遠(yuǎn)遠(yuǎn)不如，也不好維護(hù)。更深刻的原因是，對(duì)象+消息發(fā)送的威力太驚人，用途太廣，任何多態(tài)上的行為，都可以用它來(lái)做。什么都可以做，就意味著什么都盡量不要讓他來(lái)做。

其實(shí)，即便java、C#這種繼承封裝多態(tài)的面向?qū)ο笄О闳蹼u各種繁文縟節(jié)，也不妨礙人家稱霸天下，到處流行。你對(duì)象+消息發(fā)送再美妙，流行度都不及人家java一個(gè)零頭，obj c還不是靠著ios的流行才有所起色，擠入排行榜十名內(nèi)。雖然說(shuō)市場(chǎng)不能說(shuō)明什么，但是對(duì)比如此懸殊，自有其道理。

再說(shuō)，靜態(tài)類型的成員函數(shù)調(diào)用模式，廣泛存在于人類社會(huì)活動(dòng)中。人與人之間的很多事情，其實(shí)只要滿足一定的條件，必然就會(huì)發(fā)生，其后果也可以預(yù)料。很多消息的發(fā)送，其實(shí)是有考慮到對(duì)方的身份問(wèn)題，才會(huì)發(fā)起，好比小孩子跟爸媽要零用錢的消息，小孩子再發(fā)送要零用錢的消息，一定是針對(duì)親人才發(fā)起的。真相是，往往要滿足一些必要條件，消息才得以發(fā)起，當(dāng)然，只要你高興，隨時(shí)都可以發(fā)起任何消息，問(wèn)題是，這種人多半不正常。量體裁衣，針對(duì)什么樣的問(wèn)題，就應(yīng)該采用相應(yīng)的手段，一招鮮吃遍全天下，行不通的。具體問(wèn)題，必須具體分析。每種問(wèn)題，都有自己最獨(dú)特有效的解法。筆者在原教旨的面向?qū)ο笊现貜?fù)太多內(nèi)容，連自己都惡心，以后應(yīng)該很少再提及。

所以說(shuō)，面向?qū)ο蟮脑O(shè)計(jì)，首先應(yīng)該采用的必然還是繼承封裝多態(tài)的思路。在此基礎(chǔ)上，根據(jù)不同的動(dòng)態(tài)要求，采用不同策略來(lái)應(yīng)對(duì)。企圖用萬(wàn)能的消息發(fā)送來(lái)代替靜態(tài)類型面向?qū)ο蟮幕闹嚲腿缤媒┗拿嫦驅(qū)ο髞?lái)模擬一切動(dòng)態(tài)行為，兩者都是犯了同樣的毛病。可是，靜態(tài)面向?qū)ο笞鲈O(shè)計(jì)，又確實(shí)困難重重，而最終的開(kāi)發(fā)成果，總是讓人難以滿意。那是因?yàn)椋瑥V大勞動(dòng)群眾對(duì)靜態(tài)面向?qū)ο笠恍┗靖拍畹睦斫猓嬖谶@樣那樣的誤區(qū)，而由于面向?qū)ο笳Z(yǔ)言（java，C#）還缺乏一些必要機(jī)制，導(dǎo)致設(shè)計(jì)上出現(xiàn)妥協(xié)，原則性的錯(cuò)誤越積越深，以至于最后崩盤。其實(shí)，不要說(shuō)一般人，就連大人物，在面向?qū)ο笊希捕贾皇翘剿鳎帽?/span>c++之父BS，搞出來(lái)多繼承，虛繼承，iostream體系，在錯(cuò)誤的道路上，越走越遠(yuǎn)，越走越遠(yuǎn)。

好吧，其實(shí)，多繼承，還是很有作用的，在很多奇技淫巧上很有用武之地，很方便。但是，用多繼承做架構(gòu)的危險(xiǎn)，就在于其功能太過(guò)強(qiáng)大。這就意味著它要淪落成為goto啊、指針啊那樣的角色，先甭管它鉆石尷尬。多繼承的最重要角色，概念實(shí)現(xiàn)，也即是接口，也即是定義一批虛函數(shù)，里面沒(méi)有任何數(shù)據(jù)，這個(gè)抽象就必須鮮明，這一點(diǎn)，java和C#就做得很到位。就應(yīng)該從多繼承上提煉出來(lái)這么一個(gè)好東西，咦，對(duì)了，為何要有接口？沒(méi)有接口，就真的不行嗎？是的，靜態(tài)面向?qū)ο罄锩妫涌诖_實(shí)必不可少。

繼承，本質(zhì)上就是分類學(xué)。而分類，最重要一點(diǎn)，就是任何一件元素，必須也只能只屬于其中一個(gè)類，不得含糊。可以存在多種分類方式，但是，一旦確定某種分類方式，那么集合里面的一個(gè)東西，就必須只能屬于其中一大類。繼承，就是分類的一再細(xì)化，也是概念的繼續(xù)豐富。比如說(shuō)，從生物到動(dòng)物到哺乳動(dòng)物，概念包含的數(shù)據(jù)越來(lái)越多。所以說(shuō)，繼承體現(xiàn)的是數(shù)據(jù)上的豐富關(guān)系，它強(qiáng)調(diào)的是數(shù)據(jù)的積累，從遠(yuǎn)古基類開(kāi)始，一路積累下來(lái)的數(shù)據(jù)，全部必不可少，也不得重復(fù)，一旦違反這條底線，就意味著繼承體系上的錯(cuò)亂。繼承，相當(dāng)于類型的硬件，缺乏硬件元器件時(shí)，就無(wú)法完整表達(dá)該類型的概念。比如說(shuō)，人類可分為男人、女人，自然，男人有男人的陽(yáng)剛，女人有女人的陰柔，那么陰陽(yáng)同體怎么辦，集兩性之所長(zhǎng)，難道就要陰陽(yáng)人多繼承與男人女人嗎？那么，這樣繼承下來(lái)，陰陽(yáng)人豈不是就是有兩個(gè)頭，四只手，四條腿了，啊，這不是陰陽(yáng)人，這是超人，抑或是怪物。所以，陰陽(yáng)人應(yīng)該是人里面的一個(gè)分支，也即是，人的分類，就要有男人、女人、陰陽(yáng)人這三大基類。再次強(qiáng)調(diào)，繼承是為了繼承數(shù)據(jù)，而不是為了功能，功能只不過(guò)是數(shù)據(jù)的附帶品。那么，怎么描述男人的陽(yáng)剛、女人的陰柔，怎么避免陰陽(yáng)人引入后，分別從男人陽(yáng)剛，女人陰柔上復(fù)制代碼呢？此外，再次考慮平行四邊形，下面好像又有菱形，有矩形兩大類，然后身集菱形矩形的正方形，這里的分類該如何處理，難道忍不住要讓正方形多繼承菱形矩形嗎？從這個(gè)意義上講，在同一體系下，多繼承的出現(xiàn)，理所當(dāng)然，大錯(cuò)特錯(cuò)，由此可知，iostream就是敗類。iostream通過(guò)虛繼承避免絕世鉆石的出現(xiàn)，但是這個(gè)虛繼承啊，真是要讓人呵呵。C++中引入虛繼承真是，怎么說(shuō)呢，好吧，也算腦洞大開(kāi)的優(yōu)良物品，也不是完全一無(wú)是處，起碼，在iostream上就大派用場(chǎng)了。你就說(shuō)說(shuō)，虛繼承那點(diǎn)不好了？就一點(diǎn)，為了子子類的千秋基業(yè)，子類必須虛繼承基類，子類受子子類影響，就這一點(diǎn)，你能忍。

突然發(fā)現(xiàn)，文章已經(jīng)很長(zhǎng)了，不管了，這就打住。至于非侵入式接口，以后再說(shuō)吧！