此文只是雜亂的記錄一點(diǎn)點(diǎn)對(duì)于面向?qū)ο蟮膫€(gè)人看法，有些觀點(diǎn)也并非原創(chuàng)。沒什么系統(tǒng)性可言，雖然筆者稍作整理，但始終還是顯得很散亂，只是一些片段的堆積。
由于涉及的題目過于龐大，反而不知道如何下筆。先羅列一下問題，之間沒有嚴(yán)格的先后之分，純粹就是筆者想到哪里，就寫到哪里。也不一定就會(huì)解答。繼承的本質(zhì)是什么？為什么一定要有接口？c++多繼承為何飽受非議，真的就一無是處？為何筆者就反感go接口，反正go獨(dú)有的一切，筆者都是下意識(shí)的排斥？功能繁雜的Com，結(jié)合C++的自身特點(diǎn)，能否改頭換面？ ……
在原教旨眼里，面向?qū)ο蟮慕塘x就是“對(duì)象+消息發(fā)送”，整個(gè)程序由對(duì)象組成，而對(duì)象之間的就僅僅只通過發(fā)送消息響應(yīng)消息來交互，程序的功能都是在對(duì)象與對(duì)象的來回消息發(fā)送中完成，用現(xiàn)實(shí)事情類比，人類就是一個(gè)個(gè)活生生的對(duì)象，人類通過消息的往來，比如語音、文字、廣播等，有人制造新聞，有人接受到這些消息后，各自反應(yīng)，最后完成一切社會(huì)活動(dòng)。好像說得有點(diǎn)抽象，展開來說，其實(shí)就是，消息的發(fā)送者，原則上不需要事先了解目標(biāo)對(duì)象的任何背景資料，甚至他明知道對(duì)方不鳥消息，比如說，明明對(duì)方就是一個(gè)乞丐，但是并不妨礙你向他借500萬人民幣，反正，消息就是這樣發(fā)送出去的。然后，對(duì)象接受到消息之后，就各自反應(yīng)，比如說有人真的借錢給你；有人哭窮；有人嘀咕你到處借錢，無恥；……，各式各樣，不一而足。
聽起來好像人類社會(huì)活動(dòng)就是消息的往來下推動(dòng)，艱難的前進(jìn)，但是，這能拿來搬磚嗎？可以的，真的可以！即便是C語言，都可以來搞消息發(fā)送這種高大上的事情，就好像win32那樣子，通過SendMessage函數(shù)給窗口發(fā)送消息，其簽名如下：
LRESULT SendMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);
好像參數(shù)有點(diǎn)多。說白了，消息發(fā)送就相當(dāng)于成員函數(shù)函數(shù)調(diào)用的一個(gè)新馬甲，換了一種說法而已。成員函數(shù)調(diào)用，形式是這樣子，obj.fn(param1, param2, …)，涉及到對(duì)象，函數(shù)名字，還有參數(shù)，可能參數(shù)數(shù)量不止一個(gè)，參數(shù)類型也各不一樣，這些都沒關(guān)系。hWnd為窗口，也即是對(duì)象；Msg為函數(shù)名稱，現(xiàn)在用正整型編號(hào)來代表，有些消息發(fā)送系統(tǒng)用原子，qt好像是用字符串（性能堪憂啊）；wParam，lParam可以看成void*類型，也即是函數(shù)的參數(shù)，用這兩個(gè)值封裝所有的參數(shù)。天真，天下函數(shù)參數(shù)類型成千上萬，參數(shù)數(shù)目或0個(gè)、或1個(gè)、或三五個(gè)、或七八個(gè)，就wParam，lParam這兩個(gè)弱雞，就能封裝得過來？可以的，通過強(qiáng)制類型轉(zhuǎn)換，就可以讓void*的值保存char、int、float等值，又或者是將參數(shù)打包為結(jié)構(gòu)體，這樣子，就可以應(yīng)付千千萬萬的函數(shù)參數(shù)要求，這樣子，不要說，有兩個(gè)wParam，lParam來傳遞參數(shù)，就算是只有一個(gè)，也都可以應(yīng)付千千萬萬的函數(shù)要求。
那么，如何響應(yīng)消息？可以參考win32的原生api開發(fā)，這里就不展開了。原理就是，每個(gè)對(duì)象都有一個(gè)函數(shù)指針，那個(gè)函數(shù)把全部的成員函數(shù)都?jí)嚎s在一個(gè)龐大的switch語句里面，每個(gè)消息編號(hào)case分支，就代表一個(gè)成員函數(shù)，顯然，這個(gè)分支，要先將wParam，lParam里面在還原成對(duì)應(yīng)參數(shù)的實(shí)際情況，然后再執(zhí)行相應(yīng)操作。
SendMessage顯然抹去了所有窗口的具體類型信息，甭管你是按鈕、漂亮按鈕、菜單、編輯框、……，全部一律都退化成窗口對(duì)象。要往編輯框里面添加文字，就給它發(fā)送添加文字的消息，wParam，lParam就帶著要添加的文本和長度。而不是調(diào)用編輯框的添加文字的成員函數(shù)來做這個(gè)事情，最明顯的事情，就是也可以給按鈕窗口也發(fā)送添加文本的消息，雖然按鈕窗口對(duì)此消息的反應(yīng)是啥也不做。令人驚訝的是，你可以子類化一個(gè)按鈕窗口，讓它對(duì)添加文本的消息做出反應(yīng)，這完全是可以的。
顯然，原教旨的面向?qū)ο蠼塘x，的而且確，靈活，解耦徹底，不同類型對(duì)象之間的耦合關(guān)系一律不復(fù)存在，之間只有消息的往來。隨心所欲的發(fā)送消息（胡亂調(diào)用成員函數(shù)），自由自在的反應(yīng)消息（一切全無契約可言），不理睬，或者這一刻不理睬下一刻又動(dòng)了，或者這一刻動(dòng)了下一刻又拒絕反應(yīng)。甚至，消息還可以保存，排隊(duì)，求反，疊加什么的，也即是消息已經(jīng)是一種抽象數(shù)據(jù)類型了，支持多種運(yùn)算。相比于不知所謂的基于類的靜態(tài)面向?qū)ο螅ɡ^承封裝多態(tài)），簡直不可同日而語，太多的約束，呆板的語法，深入的哲學(xué)思考，架床疊屋的類型關(guān)系，也好意思學(xué)人家叫面向?qū)ο蟆?/span>
當(dāng)然，對(duì)象+消息發(fā)送這種機(jī)制，付出的代價(jià)也是很巨大的，基本上，函數(shù)調(diào)用的靜態(tài)類型檢查不服存在，所有問題都要到運(yùn)行時(shí)才能發(fā)現(xiàn)。并且，消息發(fā)送的語法也很不直觀，必須各種類型轉(zhuǎn)換，而響應(yīng)消息時(shí)又必須轉(zhuǎn)換回去。此外，為函數(shù)定義消息編號(hào)，也很惡心。不過，這些在動(dòng)態(tài)語言里面都不是問題，反正，動(dòng)態(tài)語言里面沒有靜態(tài)類型約束。另外，筆者用template、全局變量、宏等奇技淫巧，在c++里面，已經(jīng)實(shí)現(xiàn)了類型安全的消息發(fā)送框架，比如，Send(obj, kAppendText, U8String(“hello”))，而對(duì)象實(shí)現(xiàn)對(duì)消息的響應(yīng)，直接也是成員函數(shù)的形式，并且還是非侵入式的，也即是說，在main函數(shù)之前，可以隨時(shí)在任意地方給對(duì)象添加新的消息反射，所有參數(shù)上類型轉(zhuǎn)換以及返回值上的類型轉(zhuǎn)換，全部都不需要了。 但即便是這樣，也不贊成原教旨的面向?qū)ο蟮教幏簽E。原因是，用它寫出來的程序，類型層次很不清晰，相比于架構(gòu)良好的類形式的面向?qū)ο蟪绦颍勺x性遠(yuǎn)遠(yuǎn)不如，也不好維護(hù)。更深刻的原因是，對(duì)象+消息發(fā)送的威力太驚人，用途太廣，任何多態(tài)上的行為，都可以用它來做。什么都可以做，就意味著什么都盡量不要讓他來做。
其實(shí)，即便java、C#這種繼承封裝多態(tài)的面向?qū)ο笄О闳蹼u各種繁文縟節(jié)，也不妨礙人家稱霸天下，到處流行。你對(duì)象+消息發(fā)送再美妙，流行度都不及人家java一個(gè)零頭，obj c還不是靠著ios的流行才有所起色，擠入排行榜十名內(nèi)。雖然說市場不能說明什么，但是對(duì)比如此懸殊，自有其道理。
再說，靜態(tài)類型的成員函數(shù)調(diào)用模式，廣泛存在于人類社會(huì)活動(dòng)中。人與人之間的很多事情，其實(shí)只要滿足一定的條件，必然就會(huì)發(fā)生，其后果也可以預(yù)料。很多消息的發(fā)送，其實(shí)是有考慮到對(duì)方的身份問題，才會(huì)發(fā)起，好比小孩子跟爸媽要零用錢的消息，小孩子再發(fā)送要零用錢的消息，一定是針對(duì)親人才發(fā)起的。真相是，往往要滿足一些必要條件，消息才得以發(fā)起，當(dāng)然，只要你高興，隨時(shí)都可以發(fā)起任何消息，問題是，這種人多半不正常。量體裁衣，針對(duì)什么樣的問題，就應(yīng)該采用相應(yīng)的手段，一招鮮吃遍全天下，行不通的。具體問題，必須具體分析。每種問題，都有自己最獨(dú)特有效的解法。筆者在原教旨的面向?qū)ο笊现貜?fù)太多內(nèi)容，連自己都惡心，以后應(yīng)該很少再提及。
所以說，面向?qū)ο蟮脑O(shè)計(jì)，首先應(yīng)該采用的必然還是繼承封裝多態(tài)的思路。在此基礎(chǔ)上，根據(jù)不同的動(dòng)態(tài)要求，采用不同策略來應(yīng)對(duì)。企圖用萬能的消息發(fā)送來代替靜態(tài)類型面向?qū)ο蟮幕闹嚲腿缤媒┗拿嫦驅(qū)ο髞砟M一切動(dòng)態(tài)行為，兩者都是犯了同樣的毛病。可是，靜態(tài)面向?qū)ο笞鲈O(shè)計(jì)，又確實(shí)困難重重，而最終的開發(fā)成果，總是讓人難以滿意。那是因?yàn)椋瑥V大勞動(dòng)群眾對(duì)靜態(tài)面向?qū)ο笠恍┗靖拍畹睦斫猓嬖谶@樣那樣的誤區(qū)，而由于面向?qū)ο笳Z言（java，C#）還缺乏一些必要機(jī)制，導(dǎo)致設(shè)計(jì)上出現(xiàn)妥協(xié)，原則性的錯(cuò)誤越積越深，以至于最后崩盤。其實(shí)，不要說一般人，就連大人物，在面向?qū)ο笊希捕贾皇翘剿鳎帽?/span>c++之父BS，搞出來多繼承，虛繼承，iostream體系，在錯(cuò)誤的道路上，越走越遠(yuǎn)，越走越遠(yuǎn)。
好吧，其實(shí)，多繼承，還是很有作用的，在很多奇技淫巧上很有用武之地，很方便。但是，用多繼承做架構(gòu)的危險(xiǎn)，就在于其功能太過強(qiáng)大。這就意味著它要淪落成為goto啊、指針啊那樣的角色，先甭管它鉆石尷尬。多繼承的最重要角色，概念實(shí)現(xiàn)，也即是接口，也即是定義一批虛函數(shù)，里面沒有任何數(shù)據(jù)，這個(gè)抽象就必須鮮明，這一點(diǎn)，java和C#就做得很到位。就應(yīng)該從多繼承上提煉出來這么一個(gè)好東西，咦，對(duì)了，為何要有接口？沒有接口，就真的不行嗎？是的，靜態(tài)面向?qū)ο罄锩妫涌诖_實(shí)必不可少。
繼承，本質(zhì)上就是分類學(xué)。而分類，最重要一點(diǎn)，就是任何一件元素，必須也只能只屬于其中一個(gè)類，不得含糊。可以存在多種分類方式，但是，一旦確定某種分類方式，那么集合里面的一個(gè)東西，就必須只能屬于其中一大類。繼承，就是分類的一再細(xì)化，也是概念的繼續(xù)豐富。比如說，從生物到動(dòng)物到哺乳動(dòng)物，概念包含的數(shù)據(jù)越來越多。所以說，繼承體現(xiàn)的是數(shù)據(jù)上的豐富關(guān)系，它強(qiáng)調(diào)的是數(shù)據(jù)的積累，從遠(yuǎn)古基類開始，一路積累下來的數(shù)據(jù)，全部必不可少，也不得重復(fù)，一旦違反這條底線，就意味著繼承體系上的錯(cuò)亂。繼承，相當(dāng)于類型的硬件，缺乏硬件元器件時(shí)，就無法完整表達(dá)該類型的概念。比如說，人類可分為男人、女人，自然，男人有男人的陽剛，女人有女人的陰柔，那么陰陽同體怎么辦，集兩性之所長，難道就要陰陽人多繼承與男人女人嗎？那么，這樣繼承下來，陰陽人豈不是就是有兩個(gè)頭，四只手，四條腿了，啊，這不是陰陽人，這是超人，抑或是怪物。所以，陰陽人應(yīng)該是人里面的一個(gè)分支，也即是，人的分類，就要有男人、女人、陰陽人這三大基類。再次強(qiáng)調(diào)，繼承是為了繼承數(shù)據(jù)，而不是為了功能，功能只不過是數(shù)據(jù)的附帶品。那么，怎么描述男人的陽剛、女人的陰柔，怎么避免陰陽人引入后，分別從男人陽剛，女人陰柔上復(fù)制代碼呢？此外，再次考慮平行四邊形，下面好像又有菱形，有矩形兩大類，然后身集菱形矩形的正方形，這里的分類該如何處理，難道忍不住要讓正方形多繼承菱形矩形嗎？從這個(gè)意義上講，在同一體系下，多繼承的出現(xiàn)，理所當(dāng)然，大錯(cuò)特錯(cuò)，由此可知，iostream就是敗類。iostream通過虛繼承避免絕世鉆石的出現(xiàn)，但是這個(gè)虛繼承啊，真是要讓人呵呵。C++中引入虛繼承真是，怎么說呢，好吧，也算腦洞大開的優(yōu)良物品，也不是完全一無是處，起碼，在iostream上就大派用場了。你就說說，虛繼承那點(diǎn)不好了？就一點(diǎn)，為了子子類的千秋基業(yè)，子類必須虛繼承基類，子類受子子類影響，就這一點(diǎn)，你能忍。
突然發(fā)現(xiàn)，文章已經(jīng)很長了，不管了，這就打住。至于非侵入式接口，以后再說吧！