此文只是雜亂的記錄一點點對于面向對象的個人看法，有些觀點也并非原創。沒什么系統性可言，雖然筆者稍作整理，但始終還是顯得很散亂，只是一些片段的堆積。

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

在原教旨眼里，面向對象的教義就是“對象+消息發送”，整個程序由對象組成，而對象之間的就僅僅只通過發送消息響應消息來交互，程序的功能都是在對象與對象的來回消息發送中完成，用現實事情類比，人類就是一個個活生生的對象，人類通過消息的往來，比如語音、文字、廣播等，有人制造新聞，有人接受到這些消息后，各自反應，最后完成一切社會活動。好像說得有點抽象，展開來說，其實就是，消息的發送者，原則上不需要事先了解目標對象的任何背景資料，甚至他明知道對方不鳥消息，比如說，明明對方就是一個乞丐，但是并不妨礙你向他借500萬人民幣，反正，消息就是這樣發送出去的。然后，對象接受到消息之后，就各自反應，比如說有人真的借錢給你；有人哭窮；有人嘀咕你到處借錢，無恥；……，各式各樣，不一而足。

聽起來好像人類社會活動就是消息的往來下推動，艱難的前進，但是，這能拿來搬磚嗎？可以的，真的可以！即便是C語言，都可以來搞消息發送這種高大上的事情，就好像win32那樣子，通過SendMessage函數給窗口發送消息，其簽名如下：

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

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

那么，如何響應消息？可以參考win32的原生api開發，這里就不展開了。原理就是，每個對象都有一個函數指針，那個函數把全部的成員函數都壓縮在一個龐大的switch語句里面，每個消息編號case分支，就代表一個成員函數，顯然，這個分支，要先將wParam，lParam里面在還原成對應參數的實際情況，然后再執行相應操作。

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

顯然，原教旨的面向對象教義，的而且確，靈活，解耦徹底，不同類型對象之間的耦合關系一律不復存在，之間只有消息的往來。隨心所欲的發送消息(胡亂調用成員函數)，自由自在的反應消息(一切全無契約可言)，不理睬，或者這一刻不理睬下一刻又動了，或者這一刻動了下一刻又拒絕反應。甚至，消息還可以保存，排隊，求反，疊加什么的，也即是消息已經是一種抽象數據類型了，支持多種運算。相比于不知所謂的基于類的靜態面向對象(繼承封裝多態)，簡直不可同日而語，太多的約束，呆板的語法，深入的哲學思考，架床疊屋的類型關系，也好意思學人家叫面向對象。

當然，對象+消息發送這種機制，付出的代價也是很巨大的，基本上，函數調用的靜態類型檢查不服存在，所有問題都要到運行時才能發現。并且，消息發送的語法也很不直觀，必須各種類型轉換，而響應消息時又必須轉換回去。此外，為函數定義消息編號，也很惡心。不過，這些在動態語言里面都不是問題，反正，動態語言里面沒有靜態類型約束。另外，筆者用template、全局變量、宏等奇技淫巧，在c++里面，已經實現了類型安全的消息發送框架，比如，Send(obj, kAppendText, U8String(“hello”))，而對象實現對消息的響應，直接也是成員函數的形式，并且還是非侵入式的，也即是說，在main函數之前，可以隨時在任意地方給對象添加新的消息反射，所有參數上類型轉換以及返回值上的類型轉換，全部都不需要了。 但即便是這樣，也不贊成原教旨的面向對象到處泛濫。原因是，用它寫出來的程序，類型層次很不清晰，相比于架構良好的類形式的面向對象程序，可讀性遠遠不如，也不好維護。更深刻的原因是，對象+消息發送的威力太驚人，用途太廣，任何多態上的行為，都可以用它來做。什么都可以做，就意味著什么都盡量不要讓他來做。

其實，即便java、C#這種繼承封裝多態的面向對象千般弱雞各種繁文縟節，也不妨礙人家稱霸天下，到處流行。你對象+消息發送再美妙，流行度都不及人家java一個零頭，obj c還不是靠著ios的流行才有所起色，擠入排行榜十名內。雖然說市場不能說明什么，但是對比如此懸殊，自有其道理。

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

所以說，面向對象的設計，首先應該采用的必然還是繼承封裝多態的思路。在此基礎上，根據不同的動態要求，采用不同策略來應對。企圖用萬能的消息發送來代替靜態類型面向對象的荒謬就如同用僵化的面向對象來模擬一切動態行為，兩者都是犯了同樣的毛病。可是，靜態面向對象做設計，又確實困難重重，而最終的開發成果，總是讓人難以滿意。那是因為，廣大勞動群眾對靜態面向對象一些基本概念的理解，存在這樣那樣的誤區，而由于面向對象語言(java，C#)還缺乏一些必要機制，導致設計上出現妥協，原則性的錯誤越積越深，以至于最后崩盤。其實，不要說一般人，就連大人物，在面向對象上，也都只是探索，好比c++之父BS，搞出來多繼承，虛繼承，iostream體系，在錯誤的道路上，越走越遠，越走越遠。

好吧，其實，多繼承，還是很有作用的，在很多奇技淫巧上很有用武之地，很方便。但是，用多繼承做架構的危險，就在于其功能太過強大。這就意味著它要淪落成為goto啊、指針啊那樣的角色，先甭管它鉆石尷尬。多繼承的最重要角色，概念實現，也即是接口，也即是定義一批虛函數，里面沒有任何數據，這個抽象就必須鮮明，這一點，java和C#就做得很到位。就應該從多繼承上提煉出來這么一個好東西，咦，對了，為何要有接口？沒有接口，就真的不行嗎？是的，靜態面向對象里面，接口確實必不可少。

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

突然發現，文章已經很長了，不管了，這就打住。至于非侵入式接口，以后再說吧！

總結

以上是生活随笔為你收集整理的虚继承是什么意思_huaxiazhihuo的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。