作為程序員，你是使用函數(shù)式編程還是面向對象編程方式？
在本文中，擁有 10 多年軟件開發(fā)經(jīng)驗的作者從面向對象編程的三大特性——繼承、封裝、多態(tài)三大角度提出了自己的疑問，并深刻表示是時候和面向對象編程說再見了。
幾十年來我都在用面向對象的語言編程。我用過的第一個面向對象的語言是 C++，后來是 Smalltalk，最后是 .NET 和 Java。
我曾經(jīng)對使用繼承、封裝和多態(tài)充滿熱情。它們是范式的三大支柱。
我渴望實現(xiàn)重用之美，并在這個令人興奮的新天地中享受前輩們積累的智慧。
想到將現(xiàn)實世界的一切映射到類中，使得整個世界都可以得到整齊的規(guī)劃，我無法抑制自己的興奮。
乍一看，繼承似乎是面向對象范式的最大優(yōu)勢。所有新手教程講解繼承時都會拿出最簡單的繼承的例子，而這個例子似乎很符合邏輯。
我囫圇吞下這一切，然后帶著新發(fā)現(xiàn)興沖沖地奔向世界了。
帶著滿腔的信仰和解決問題的熱情，我開始構建類的層次結構然后寫代碼。似乎一切皆在掌控中。
我永遠不會忘記我準備從已有的類繼承并實現(xiàn)重用的那一天。那是我期待已久的時刻。
后來有了新的項目，我想起了另一個項目里我很喜歡的那個類。
沒問題，重用拯救一切。我只需要把那個類拿過來用就好了。
嗯……其實……不僅是那一個類。還得把父類也拿過來。但……應該就可以了吧。
額……不對，似乎還需要父類的父類……還有……嗯，我們需要所有的祖先類。好吧好吧……搞定了。沒問題。
不錯。但編譯不過，怎么回事？哦我知道了……這個對象還需要另一個對象。所以那個也得拿過來。沒問題……
等等……我不僅需要那個對象，還需要那個對象的父類，和父類的父類，和……包含的所有對象的所有祖先……
Erlang 的創(chuàng)建者 JoeArmstrong 有句名言：
面向對象語言的問題在于，它們依賴于特定的環(huán)境。你想要個香蕉，但拿到的卻是拿著香蕉的猩猩，乃至最后你擁有了整片叢林。
這個問題的解決方法是，不要把類層次建得那么深。但如果繼承是重用的關鍵，那么給繼承機制添加的任何限制都會限制重用。對吧？
那我們可憐的面向對象程序員該怎么辦？指望一杯三聚氰胺奶維系我們的健康嗎？
答案就是：包含和委托（Contain and Delegate）。一會兒會詳細解釋。
早晚你會遇到下面這種惡心的問題，有些語言甚至根本解決不了。
大多數(shù)面向對象語言都不支持這種情況，盡管看上去似乎很符合邏輯。為什么面向對象語言支持這種情況如此困難？
Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
function start() {
}
}
Class Printer inherits from PoweredDevice {
function start() {
}
}
Class Copier inherits from Scanner, Printer {
}
注意 Scanner 和 Printer 類都實現(xiàn)了名為 start 方法。
那么問題來了，Copier繼承哪個start？是Scanner的還是Printer的？肯定不可能同時繼承啊。
但是，但是……要是必須這樣建模該怎么辦？我需要重用！
Class 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()
}
}
注意現(xiàn)在 Copier 類包含一個 Printer 實例和一個 Scanner 實例。然后將 start 函數(shù)委托給 Printer 類的實現(xiàn)。要委托給 Scanner 也很簡單。
好吧，那我盡量使用較淺的類層次結構，并保證里面沒有環(huán)，這樣就不會出現(xiàn)菱形繼承了。
似乎一切都解決了。直到我們發(fā)現(xiàn)……
我前一天工作得好好的代碼今天出錯了！關鍵是，我沒有改任何代碼！
但改動的不是我的代碼。似乎改動來自我繼承的那個類。
看看下面這個基類（用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
}
}
重要提示：注意加了注釋的那一行。稍后這行的改動將會導致別的東西出錯。
這個類的接口上有兩個函數(shù)：add() 和 addAll()。add() 函數(shù)負責添加一個元素，addAll() 函數(shù)會調用 add 函數(shù)添加多個元素。
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類的特化。兩者行為上的唯一區(qū)別就是ArrayCount會維護一個count，記錄元素的個數(shù)。
Array的add()給局部的ArrayList添加一個元素。
Array的addAll()針對每個元素調用局部的ArrayList的add方法。
ArrayCount的add()調用父類的add()然后增加count。
ArrayCount的addAll()調用父類的addAll()然后給count增加相當于元素個數(shù)的數(shù)。
現(xiàn)在是出問題的地方?；愔屑幼⑨尩哪切写a現(xiàn)在改成這樣：
public void addAll(Object elements[])
{
for (int i = 0; i < elements.length; ++i)
add(elements[i]); // this line was changed
}
從基類的作者的角度來看，這個類實現(xiàn)的功能完全沒有變化。而且所有自動化測試也都通過來了。
但是基類的作者忘記了繼承的類。而繼承類的作者被錯誤吵醒了。
現(xiàn)在ArrayCount的addAll()調用父類的addAll()，后者在內部調用add()，而add()被繼承類重載了。
因此，每次繼承類的add()被調用時，count都會增加，然后在繼承類的addAll()被調用時再次增加。
既然會發(fā)生這種現(xiàn)象，那么繼承類的作者必須清楚基類是怎樣實現(xiàn)的。而且，基類的每個改動必須要通知所有繼承類的作者，因為這些改動可能會以不可預知的方式破壞繼承類。
唉！這個巨大的裂隙威脅到了整個繼承支柱的穩(wěn)定。
使用包含和委托，可以從白盒編程轉到黑盒編程。白盒編程的意思是說，寫繼承類時必須要了解基類的實現(xiàn)。
而黑盒編程可以完全無視基類的實現(xiàn)，因為不可能通過重載函數(shù)的方式向基類注入代碼。只需要關注接口即可。
在面向對象語言中實現(xiàn)包含和委托并不容易。它們是為了繼承方便而設計的。
如果你和我一樣，你就會開始反思這個繼承了。但更重要的是，這些問題應當引起你對于通過層次結構進行分類的反思。
每到一個新公司時，我都要為在哪兒保存公司文檔（即員工手冊）而糾結。
是應該建一個Documents文件夾，然后在里面建個Company呢？
還是應該建個Company文件夾，然后在里面建個Documents呢？
層次分類的思想是因為基類（父類）更通用，繼承類（子類）更專用。沿著繼承鏈越往下走，概念就越專用（見上面的形狀層次）。
但如果父節(jié)點和子節(jié)點能隨意交換位置，那么顯然這種模型是有問題的。
真實世界里有很多包含關系（或者叫做獨占關系）的層次結構。
但你找不到層次分類。仔細想一下。面向對象范式是根據(jù)充滿了各種對象的真實世界建立的。但它用錯了模型——層次分類在真實世界中沒有類比。
但真實世界里到處都是層次包含關系。層次包含關系的一個非常好的例子就是你的襪子。襪子放在裝襪子的抽屜里，然后抽屜包含在衣柜里，衣柜包含在臥室里，臥室包含在房子里，等等。
硬盤上的目錄也是層次包含關系的另一個例子——它們包含文件。
仔細想一下公司文檔，就會發(fā)現(xiàn)其實放在哪兒都無所謂。我可以放在Documents目錄下或者放在Stuff目錄下也可以。
標簽是沒有順序或層次的（這同時解決了菱形繼承問題）。
標簽可以類比為接口，因為同一份文檔可以有多種類型。
但既然有了這么多裂縫，估計繼承的支柱已經(jīng)倒塌了。
對象狀態(tài)變量被保護起來防止外部訪問，即它們被封裝在對象內部。
我們不需要再操心那些可能被不知道誰訪問的全局變量。
為了提高效率，對象傳遞給函數(shù)時傳遞的是引用，而不是值。
也就是說，函數(shù)不會傳遞對象本身，而是傳遞指向對象的一個引用或指針。
如果一個對象的引用被傳遞給另一個對象的構造函數(shù)，構造函數(shù)就能將這個對象引用放到私有變量中，用封裝保護起來。
為什么不是？因為其他代碼也可能擁有指向該對象的指針，比如調用構造函數(shù)的那段代碼。它必須有指向對象的引用，否則沒辦法傳遞給構造函數(shù)。
構造函數(shù)必須要復制傳遞過來的對象。而且不能是淺復制，必須是深復制，即傳入的對象內包含的所有對象和所有對象中包含的所有對象……都必須要復制。
而且更糟糕的是，并非所有對象都能復制的。一些擁有操作系統(tǒng)資源的對象，最好的情況是復制無效，最糟糕的情況是根本不可能復制。
多態(tài)是面向對象的三位一體中永遠被人拋棄的那一位。
并不是因為多態(tài)不好，而是因為實現(xiàn)多態(tài)并不需要面向對象語言。
接口也能實現(xiàn)多態(tài)，而且不需要面向對象的負擔。
而且，接口也不會限制你能混入的不同行為的數(shù)目。
所以，無需多言，我們可以告別面向對象的多態(tài)，去迎接基于接口的多態(tài)吧。
當然，面向對象在早期承諾了許多。而直到今天，這些承諾依然在教室里、博客上和網(wǎng)上資源中傳授給青澀的程序員們。
我花了多年才意識到面向對象的謊言。以前我也曾經(jīng)青澀，曾經(jīng)輕信。
去擁抱函數(shù)式編程吧。過去幾年我用得非常舒服。
-END-
來源：CSDN
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
