面向對象編程，再見！

作為程序員，你是使用函數式編程還是面向對象編程方式？在本文中，擁有 10 多年軟體開發經驗的作者從面向對象編程的三大特性——繼承、封裝、多態三大角度提出了自己的疑問，並深刻表示是時候和面向對象編程說再見了。

幾十年來我都在用面向對象的語言編程。我用過的第一個面向對象的語言是 C++，後來是 Smalltalk，最後是 .NET 和 Java。

我曾經對使用繼承、封裝和多態充滿熱情。它們是範式的三大支柱。

我渴望實現重用之美，並在這個令人興奮的新天地中享受前輩們積累的智慧。

想到將現實世界的一切映射到類中，使得整個世界都可以得到整齊的規劃，我無法抑制自己的興奮。

然而我大錯特錯了。

繼承，倒塌的第一根支柱

乍一看，繼承似乎是面向對象範式的最大優勢。所有新手教程講解繼承時都會拿出最簡單的繼承的例子，而這個例子似乎很符合邏輯。

然後就是滿篇的重用了。甚至以後的一切都是重用了。

我囫圇吞下這一切，然後帶著新發現興沖沖地奔向世界了。

香蕉猴子叢林問題

帶著滿腔的信仰和解決問題的熱情，我開始構建類的層次結構然後寫代碼。似乎一切皆在掌控中。

我永遠不會忘記我準備從已有的類繼承並實現重用的那一天。那是我期待已久的時刻。

後來有了新的項目，我想起了另一個項目里我很喜歡的那個類。

沒問題，重用拯救一切。我只需要把那個類拿過來用就好了。

嗯……其實……不僅是那一個類。還得把父類也拿過來。但……應該就可以了吧。

額……不對，似乎還需要父類的父類……還有……嗯，我們需要所有的祖先類。好吧好吧……搞定了。沒問題。

不錯。但編譯不過，怎麼回事？哦我知道了……這個對象還需要另一個對象。所以那個也得拿過來。沒問題……

等等……我不僅需要那個對象，還需要那個對象的父類，和父類的父類，和……包含的所有對象的所有祖先……

唉……

Erlang 的創建者 JoeArmstrong 有句名言：

面向對象語言的問題在於，它們依賴於特定的環境。你想要個香蕉，但拿到的卻是拿著香蕉的猩猩，乃至最後你擁有了整片叢林。

香蕉猴子叢林的解決方法

這個問題的解決方法是，不要把類層次建得那麼深。但如果繼承是重用的關鍵，那麼給繼承機制添加的任何限制都會限制重用。對吧？

沒錯。

那我們可憐的面向對象程序員該怎麼辦？指望一杯三聚氰胺奶維繫我們的健康嗎？

答案就是：包含和委託（Contain and Delegate）。一會兒會詳細解釋。

菱形繼承問題

早晚你會遇到下面這種噁心的問題，有些語言甚至根本解決不了。

大多數面向對象語言都不支持這種情況，儘管看上去似乎很符合邏輯。為什麼面向對象語言支持這種情況如此困難？

來看看下面的偽代碼：

注意 Scanner 和 Printer 類都實現了名為 start 方法。

那麼問題來了，Copier繼承哪個start？是Scanner的還是Printer的？肯定不可能同時繼承啊。

菱形繼承的解決

解決方案很簡單：不要這樣做。

沒錯。大多數面向對象都不讓你這麼干。

但是，但是……要是必須這樣建模該怎麼辦？我需要重用！

那就必須使用包含和委託。

注意現在 Copier 類包含一個 Printer 實例和一個 Scanner 實例。然後將 start 函數委託給 Printer 類的實現。要委託給 Scanner 也很簡單。

這個問題是繼承這根支柱上的另一條裂縫。

脆弱的基類問題

好吧，那我盡量使用較淺的類層次結構，並保證裡面沒有環，這樣就不會出現菱形繼承了。

似乎一切都解決了。直到我們發現……

我前一天工作得好好的代碼今天出錯了！關鍵是，我沒有改任何代碼！

嗯也許是個 bug……但等等……的確有些改動……

但改動的不是我的代碼。似乎改動來自我繼承的那個類。

為什麼基類的改動會破壞我的代碼？

原來是這樣……

看看下面這個基類（用Java寫的，但就算你不懂Java，應該也很容易看懂）：

重要提示：注意加了注釋的那一行。稍後這行的改動將會導致別的東西出錯。

這個類的介面上有兩個函數：add() 和 addAll()。add() 函數負責添加一個元素，addAll() 函數會調用 add 函數添加多個元素。

下面是繼承的類：

ArrayCount類是通用的Array類的特化。兩者行為上的唯一區別就是ArrayCount會維護一個count，記錄元素的個數。

我們來仔細看看這兩個類。

Array的add()給局部的ArrayList添加一個元素。

Array的addAll()針對每個元素調用局部的ArrayList的add方法。

ArrayCount的add()調用父類的add()然後增加count。

ArrayCount的addAll()調用父類的addAll()然後給count增加相當於元素個數的數。

一切都很正常。

現在是出問題的地方。基類中加註釋的那行代碼現在改成這樣：

從基類的作者的角度來看，這個類實現的功能完全沒有變化。而且所有自動化測試也都通過來了。

但是基類的作者忘記了繼承的類。而繼承類的作者被錯誤吵醒了。

現在ArrayCount的addAll()調用父類的addAll()，後者在內部調用add()，而add()被繼承類重載了。

因此，每次繼承類的add()被調用時，count都會增加，然後在繼承類的addAll()被調用時再次增加。

count被增加了兩次。

既然會發生這種現象，那麼繼承類的作者必須清楚基類是怎樣實現的。而且，基類的每個改動必須要通知所有繼承類的作者，因為這些改動可能會以不可預知的方式破壞繼承類。

唉！這個巨大的裂隙威脅到了整個繼承支柱的穩定。

脆弱的基類的解決方法

這個問題還得要包含和委託來解決。

使用包含和委託，可以從白盒編程轉到黑盒編程。白盒編程的意思是說，寫繼承類時必須要了解基類的實現。

而黑盒編程可以完全無視基類的實現，因為不可能通過重載函數的方式向基類注入代碼。只需要關注介面即可。

這種趨勢太討厭了……

繼承本應帶來最好用的重用。

在面向對象語言中實現包含和委託並不容易。它們是為了繼承方便而設計的。

如果你和我一樣，你就會開始反思這個繼承了。但更重要的是，這些問題應當引起你對於通過層次結構進行分類的反思。

層次結構的問題

每到一個新公司時，我都要為在哪兒保存公司文檔（即員工手冊）而糾結。

是應該建一個Documents文件夾，然後在裡面建個Company呢？

還是應該建個Company文件夾，然後在裡面建個Documents呢？

兩者都可以。但哪個是正確的？哪個更好？

層次分類的思想是因為基類（父類）更通用，繼承類（子類）更專用。沿著繼承鏈越往下走，概念就越專用（見上面的形狀層次）。

但如果父節點和子節點能隨意交換位置，那麼顯然這種模型是有問題的。

層次結構的解決

真正的問題出在……

層次分類是錯誤的。

那層次分類應該用在哪裡？

包含關係。

真實世界裡有很多包含關係（或者叫做獨佔關係）的層次結構。

但你找不到層次分類。仔細想一下。面向對象範式是根據充滿了各種對象的真實世界建立的。但它用錯了模型——層次分類在真實世界中沒有類比。

但真實世界裡到處都是層次包含關係。層次包含關係的一個非常好的例子就是你的襪子。襪子放在裝襪子的抽屜里，然後抽屜包含在衣櫃里，衣櫃包含在卧室里，卧室包含在房子里，等等。

硬碟上的目錄也是層次包含關係的另一個例子——它們包含文件。

那我們該怎樣分類呢？

仔細想一下公司文檔，就會發現其實放在哪兒都無所謂。我可以放在Documents目錄下或者放在Stuff目錄下也可以。

我選擇的分類法是標籤。我給它加上不同的標籤。

標籤是沒有順序或層次的（這同時解決了菱形繼承問題）。

標籤可以類比為介面，因為同一份文檔可以有多種類型。

但既然有了這麼多裂縫，估計繼承的支柱已經倒塌了。

再見，繼承。

封裝，倒塌的第二根支柱

乍一看，封裝似乎是面向對象編程的第二大好處。

對象狀態變數被保護起來防止外部訪問，即它們被封裝在對象內部。

我們不需要再操心那些可能被不知道誰訪問的全局變數。

封裝是變數的保險柜。

封裝太偉大了！

封裝萬歲……

直到你遇到了這個問題……

引用問題

為了提高效率，對象傳遞給函數時傳遞的是引用，而不是值。

也就是說，函數不會傳遞對象本身，而是傳遞指向對象的一個引用或指針。

如果一個對象的引用被傳遞給另一個對象的構造函數，構造函數就能將這個對象引用放到私有變數中，用封裝保護起來。

但這個傳遞的對象不是安全的！

為什麼不是？因為其他代碼也可能擁有指向該對象的指針，比如調用構造函數的那段代碼。它必須有指向對象的引用，否則沒辦法傳遞給構造函數。

引用的解決

構造函數必須要複製傳遞過來的對象。而且不能是淺複製，必須是深複製，即傳入的對象內包含的所有對象和所有對象中包含的所有對象……都必須要複製。

完全沒有效率。

而且更糟糕的是，並非所有對象都能複製的。一些擁有操作系統資源的對象，最好的情況是複製無效，最糟糕的情況是根本不可能複製。

所有主流面向對象語言都有這個問題。

再見，封裝。

多態，倒塌的第三根支柱

多態是面向對象的三位一體中永遠被人拋棄的那一位。

就像是三人組中的Larry Fine。

不管他們去哪兒都會帶著他，但他永遠是配角。

並不是因為多態不好，而是因為實現多態並不需要面向對象語言。

介面也能實現多態，而且不需要面向對象的負擔。

而且，介面也不會限制你能混入的不同行為的數目。

所以，無需多言，我們可以告別面向對象的多態，去迎接基於介面的多態吧。

破碎的承諾

當然，面向對象在早期承諾了許多。而直到今天，這些承諾依然在教室里、博客上和網上資源中傳授給青澀的程序員們。

我花了多年才意識到面向對象的謊言。以前我也曾經青澀，曾經輕信。

然後我發現被騙了。

再見，面向對象編程。

那該怎麼辦？

去擁抱函數式編程吧。過去幾年我用得非常舒服。

但話說在先，我並沒有給你做出任何承諾。眼見為實。

一朝被蛇咬十年怕井繩。

你懂的。

原文：https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

作者：Charles Scalfani。

譯者：彎月，責編：屠敏

微信改版了，

想快速看到CSDN的熱乎文章，

趕快把CSDN公眾號設為星標吧，

打開公眾號，點擊「設為星標」就可以啦！

2018 AI開發者大會

只講技術，拒絕空談

2018 AI開發者大會首輪重磅嘉賓及深度議題現已火熱出爐，掃碼搶「鮮」看。國慶特惠，購票立享5折優惠！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！