拜拜！面向物件程式設計
幾十年來我都在用面向物件的語言程式設計。我用過的第一個面向物件的語言是 C++，後來是 Smalltalk，最後是 .NET 和 Java。
我曾經對使用繼承、封裝和多型充滿熱情。它們是正規化的三大支柱。
我渴望實現重用之美，並在這個令人興奮的新天地中享受前輩們積累的智慧。
想到將現實世界的一切對映到類中，使得整個世界都可以得到整齊的規劃，我無法抑制自己的興奮。
然而我大錯特錯了。
繼承，倒塌的第一根支柱
乍一看，繼承似乎是面向物件正規化的最大優勢。所有新手教程講解繼承時都會拿出最簡單的繼承的例子，而這個例子似乎很符合邏輯。
然後就是滿篇的重用了。甚至以後的一切都是重用了。
我囫圇吞下這一切，然後帶著新發現興沖沖地奔向世界了。
香蕉猴子叢林問題
帶著滿腔的信仰和解決問題的熱情，我開始構建類的層次結構然後寫程式碼。似乎一切皆在掌控中。
我永遠不會忘記我準備從已有的類繼承並實現重用的那一天。那是我期待已久的時刻。
後來有了新的專案，我想起了另一個專案裡我很喜歡的那個類。
沒問題，重用拯救一切。我只需要把那個類拿過來用就好了。
嗯……其實……不僅是那一個類。還得把父類也拿過來。但……應該就可以了吧。
額……不對，似乎還需要父類的父類……還有……嗯，我們需要所有的祖先類。好吧好吧……搞定了。沒問題。
不錯。但編譯不過，怎麼回事？哦我知道了……這個物件還需要另一個物件。所以那個也得拿過來。沒問題……
等等……我不僅需要那個物件，還需要那個物件的父類，和父類的父類，和……包含的所有物件的所有祖先……
唉……
Erlang 的建立者 JoeArmstrong 有句名言：
面嚮物件語言的問題在於，它們依賴於特定的環境。你想要個香蕉，但拿到的卻是拿著香蕉的猩猩，乃至最後你擁有了整片叢林。
香蕉猴子叢林的解決方法
這個問題的解決方法是，不要把類層次建得那麼深。但如果繼承是重用的關鍵，那麼給繼承機制新增的任何限制都會限制重用。對吧？
沒錯。
那我們可憐的面向物件程式員該怎麼辦？指望一杯三聚氰胺奶維繫我們的健康嗎？
答案就是：包含和委託（Contain and Delegate）。一會兒會詳細解釋。
菱形繼承問題
早晚你會遇到下面這種噁心的問題，有些語言甚至根本解決不了。
大多數面嚮物件語言都不支援這種情況，儘管看上去似乎很符合邏輯。為什麼面嚮物件語言支援這種情況如此困難？
來看看下面的虛擬碼：
Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
function start() {
}
}
Class Printer inherits from PoweredDevice {
function start() {
}
}
Class Copier inherits from Scanner, Printer {
}
注意 Scanner 和 Printer 類都實現了名為 start 方法。
那麼問題來了，Copier繼承哪個start？是Scanner的還是Printer的？肯定不可能同時繼承啊。
菱形繼承的解決
解決方案很簡單：不要這樣做。
沒錯。大多數面向物件都不讓你這麼幹。
但是，但是……要是必須這樣建模該怎麼辦？我需要重用！
那就必須使用 包含和委託 。
lass PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
function start() {
}
}
Class Printer inherits from PoweredDevice {
function start() {
}
}
Class Copier {
Scanner scanner
Printer printer
function start() {
printer.start()
}
}
注意現在 Copier 類包含一個 Printer 例項和一個 Scanner 例項。然後將 start 函式委託給 Printer 類的實現。要委託給 Scanner 也很簡單。
這個問題是繼承這根支柱上的另一條裂縫。
脆弱的基類問題
好吧，那我儘量使用較淺的類層次結構，並保證裡面沒有環，這樣就不會出現菱形繼承了。
似乎一切都解決了。直到我們發現……
我前一天工作得好好的程式碼今天出錯了！關鍵是，我沒有改任何程式碼！
嗯也許是個 bug……但等等……的確有些改動……
但改動的不是我的程式碼。似乎改動來自我繼承的那個類。
為什麼基類的改動會破壞我的程式碼？
原來是這樣……
看看下面這個基類（用Java寫的，但就算你不懂Java，應該也很容易看懂）：
import java.util.ArrayList;
public class Array
{
private ArrayList<Object> a = new ArrayList<Object>();
public void add(Object element)
{
a.add(element);
}
public void addAll(Object elements[])
{
for (int i = 0; i < elements.length; ++i)
a.add(elements[i]); // this line is going to be changed
}
}
重要提示：注意加了註釋的那一行。稍後這行的改動將會導致別的東西出錯。
這個類的介面上有兩個函式：add() 和 addAll()。add() 函式負責新增一個元素，addAll() 函式會呼叫 add 函式新增多個元素。
下面是繼承的類：
public class ArrayCount extends Array
{
private int count = 0;
@Override
public void add(Object element)
{
super.add(element);
++count;
}
@Override
public void addAll(Object elements[])
{
super.addAll(elements);
count += elements.length;
}
}
ArrayCount類是通用的Array類的特化。兩者行為上的唯一區別就是ArrayCount會維護一個count，記錄元素的個數。
我們來仔細看看這兩個類。
Array的add()給區域性的ArrayList新增一個元素。
Array的addAll()針對每個元素呼叫區域性的ArrayList的add方法。
ArrayCount的add()呼叫父類的add()然後增加count。
ArrayCount的addAll()呼叫父類的addAll()然後給count增加相當於元素個數的數。
一切都很正常。
現在是出問題的地方。基類中加註釋的那行程式碼現在改成這樣：
public void addAll(Object elements[])
{
for (int i = 0; i < elements.length; ++i)
add(elements[i]); // this line was changed
}
從基類的作者的角度來看，這個類實現的功能完全沒有變化。而且所有自動化測試也都通過來了。
但是基類的作者忘記了繼承的類。而繼承類的作者被錯誤吵醒了。
現在ArrayCount的addAll()呼叫父類的addAll()，後者在內部呼叫add()，而add()被繼承類過載了。
因此，每次繼承類的add()被呼叫時，count都會增加，然後在繼承類的addAll()被呼叫時再次增加。
count被增加了兩次。
既然會發生這種現象，那麼繼承類的作者必須清楚基類是怎樣實現的。而且，基類的每個改動必須要通知所有繼承類的作者，因為這些改動可能會以不可預知的方式破壞繼承類。
唉！這個巨大的裂隙威脅到了整個繼承支柱的穩定。
脆弱的基類的解決方法
這個問題還得要包含和委託來解決。
使用包含和委託，可以從白盒程式設計轉到黑盒程式設計。白盒程式設計的意思是說，寫繼承類時必須要了解基類的實現。
而黑盒程式設計可以完全無視基類的實現，因為不可能通過過載函式的方式向基類注入程式碼。只需要關注介面即可。
這種趨勢太討厭了……
繼承本應帶來最好用的重用。
在面嚮物件語言中實現包含和委託並不容易。它們是為了繼承方便而設計的。
如果你和我一樣，你就會開始反思這個繼承了。但更重要的是，這些問題應當引起你對於通過層次結構進行分類的反思。
層次結構的問題
每到一個新公司時，我都要為在哪兒儲存公司文件（即員工手冊）而糾結。
是應該建一個Documents資料夾，然後在裡面建個Company呢？
還是應該建個Company資料夾，然後在裡面建個Documents呢？
兩者都可以。但哪個是正確的？哪個更好？
層次分類的思想是因為基類（父類）更通用，繼承類（子類）更專用。沿著繼承鏈越往下走，概念就越專用（見上面的形狀層次）。
但如果父節點和子節點能隨意交換位置，那麼顯然這種模型是有問題的。
層次結構的解決
真正的問題出在……
層次分類是錯誤的。
那層次分類應該用在哪裡？
包含關係。
真實世界裡有很多包含關係（或者叫做獨佔關係）的層次結構。
但你找不到層次分類。仔細想一下。面向物件正規化是根據充滿了各種物件的真實世界建立的。但它用錯了模型——層次分類在真實世界中沒有類比。
但真實世界裡到處都是層次包含關係。層次包含關係的一個非常好的例子就是你的襪子。襪子放在裝襪子的抽屜裡，然後抽屜包含在衣櫃裡，衣櫃包含在臥室裡，臥室包含在房子裡，等等。
硬碟上的目錄也是層次包含關係的另一個例子——它們包含檔案。
那我們該怎樣分類呢？
仔細想一下公司文件，就會發現其實放在哪兒都無所謂。我可以放在Documents目錄下或者放在Stuff目錄下也可以。
我選擇的分類法是標籤。我給它加上不同的標籤。
Document
Company
Handbook
標籤是沒有順序或層次的（這同時解決了菱形繼承問題）。
標籤可以類比為介面，因為同一份文件可以有多種型別。
但既然有了這麼多裂縫，估計繼承的支柱已經倒塌了。
再見，繼承。
封裝，倒塌的第二根支柱
乍一看，封裝似乎是面向物件程式設計的第二大好處。
物件狀態變數被保護起來防止外部訪問，即它們被封裝在物件內部。
我們不需要再操心那些可能被不知道誰訪問的全域性變數。
封裝是變數的保險櫃。
封裝太偉大了！
封裝萬歲……
直到你遇到了這個問題……
引用問題
為了提高效率，物件傳遞給函式時傳遞的是引用，而不是值。
也就是說，函式不會傳遞物件本身，而是傳遞指向物件的一個引用或指標。
如果一個物件的引用被傳遞給另一個物件的建構函式，建構函式就能將這個物件引用放到私有變數中，用封裝保護起來。
但這個傳遞的物件不是安全的！
為什麼不是？因為其他程式碼也可能擁有指向該物件的指標，比如呼叫建構函式的那段程式碼。它必須有指向物件的引用，否則沒辦法傳遞給建構函式。
引用的解決
建構函式必須要複製傳遞過來的物件。而且不能是淺複製，必須是深複製，即傳入的物件內包含的所有物件和所有物件中包含的所有物件……都必須要複製。
完全沒有效率。
而且更糟糕的是，並非所有物件都能複製的。一些擁有作業系統資源的物件，最好的情況是複製無效，最糟糕的情況是根本不可能複製。
所有主流面嚮物件語言都有這個問題。
再見，封裝。
多型，倒塌的第三根支柱
多型是面向物件的三位一體中永遠被人拋棄的那一位。
就像是三人組中的Larry Fine。
不管他們去哪兒都會帶著他，但他永遠是配角。
並不是因為多型不好，而是因為實現多型並不需要面嚮物件語言。
介面也能實現多型，而且不需要面向物件的負擔。
而且，介面也不會限制你能混入的不同行為的數目。
所以，無需多言，我們可以告別面向物件的多型，去迎接基於介面的多型吧。
破碎的承諾
當然，面向物件在早期承諾了許多。而直到今天，這些承諾依然在教室裡、部落格上和網上資源中傳授給青澀的程式設計師們。
我花了多年才意識到面向物件的謊言。以前我也曾經青澀，曾經輕信。
然後我發現被騙了。
再見，面向物件程式設計。
那該怎麼辦
去擁抱 函數語言程式設計 吧。過去幾年我用得非常舒服。
但話說在先，我並沒有給你做出任何承諾。眼見為實。
一朝被蛇咬十年怕井繩。
你懂的。
原文釋出時間為：2018-10-22
本文作者：彎月