歡迎光臨
每天分享高質量文章

面向物件程式設計,再見!

導讀:作為程式員,你是使用函式式程式設計還是面向物件程式設計方式?在本文中,擁有 10 多年軟體開發經驗的作者從面向物件程式設計的三大特性——繼承、封裝、多型三大角度提出了自己的疑問,並深刻表示是時候和麵向物件程式設計說再見了。

作者:Charles Scalfani

譯者:彎月,責編:屠敏

來源:CSDN(ID:CSDNnews)

原文:medium.com

幾十年來我都在用面向物件的語言程式設計。我用過的第一個面向物件的語言是 C++,後來是 Smalltalk,最後是 .NET 和 Java。

我曾經對使用繼承、封裝和多型充滿熱情。它們是正規化的三大支柱。

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

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

然而我大錯特錯了。

01 繼承,倒塌的第一根支柱

乍一看,繼承似乎是面向物件正規化的最大優勢。所有新手教程講解繼承時都會拿出最簡單的繼承的例子,而這個例子似乎很符合邏輯。

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

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

1. 香蕉猴子叢林問題

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

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

後來有了新的專案,我想起了另一個專案裡我很喜歡的那個類。

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

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

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

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

等等……我不僅需要那個物件,還需要那個物件的父類,和父類的父類,和……包含的所有物件的所有祖先……

唉……

Erlang 的建立者 Joe Armstrong 有句名言:

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

2. 香蕉猴子叢林的解決方法

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

沒錯。

那我們可憐的面向物件程式員該怎麼辦?指望一杯三聚氰胺奶維繫我們的健康嗎?

答案就是:包含和委託(Contain and Delegate)。一會兒會詳細解釋。

3. 菱形繼承問題

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

大多數面向物件語言都不支援這種情況,儘管看上去似乎很符合邏輯。為什麼面向物件語言支援這種情況如此困難?

來看看下麵的偽程式碼:

Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
  function start() {
  }
}
Class Printer inherits from PoweredDevice {
  function start() {
  }
}
Class Copier inherits from ScannerPrinter {
}

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

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

4. 菱形繼承的解決

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

沒錯。大多數面向物件都不讓你這麼乾。

但是,但是……要是必須這樣建模該怎麼辦?我需要重用!

那就必須使用包含和委託

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()
  }
}

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

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

5. 脆弱的基類問題

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

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

我前一天工作得好好的程式碼今天出錯了!關鍵是,我沒有改任何程式碼!

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

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

為什麼基類的改動會破壞我的程式碼?

原來是這樣……

看看下麵這個基類(用Java寫的,但就算你不懂Java,應該也很容易看懂):

import java.util.ArrayList;

public class Array
{
  private ArrayList a = new ArrayList();

  public void add(Object element)
  
{
    a.add(element);
  }

  public void addAll(Object elements[])
  
{
    for (int i = 0; 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       add(elements[i]); // this line was changed
  }

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

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

現在ArrayCount的addAll()呼叫父類的addAll(),後者在內部呼叫add(),而add()被繼承類多載了。

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

count被增加了兩次。

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

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

6. 脆弱的基類的解決方法

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

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

而黑盒程式設計可以完全無視基類的實現,因為不可能透過多載函式的方式向基類註入程式碼。只需要關註介面即可。

這種趨勢太討厭了……

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

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

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

7. 層次結構的問題

每到一個新公司時,我都要為在哪兒儲存公司檔案(即員工手冊)而糾結。

是應該建一個Documents檔案夾,然後在裡面建個Company呢?

還是應該建個Company檔案夾,然後在裡面建個Documents呢?

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

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

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

8. 層次結構的解決

真正的問題出在……

層次分類是錯誤的。

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

包含關係。

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

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

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

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

那我們該怎樣分類呢?

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

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

Document
Company
Handbook

標簽是沒有順序或層次的(這同時解決了菱形繼承問題)。

標簽可以類比為介面,因為同一份檔案可以有多種型別。

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

再見,繼承。

02 封裝,倒塌的第二根支柱 

乍一看,封裝似乎是面向物件程式設計的第二大好處。

物件狀態變數被保護起來防止外部訪問,即它們被封裝在物件內部。

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

封裝是變數的保險櫃。

封裝太偉大了!

封裝萬歲…… 

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

1. 取用問題

為了提高效率,物件傳遞給函式時傳遞的是取用,而不是值。

也就是說,函式不會傳遞物件本身,而是傳遞指向物件的一個取用或指標。

如果一個物件的取用被傳遞給另一個物件的建構式,建構式就能將這個物件取用放到私有變數中,用封裝保護起來。

但這個傳遞的物件不是安全的!

為什麼不是?因為其他程式碼也可能擁有指向該物件的指標,比如呼叫建構式的那段程式碼。它必須有指向物件的取用,否則沒辦法傳遞給建構式。

2. 取用的解決

建構式必須要複製傳遞過來的物件。而且不能是淺複製,必須是深複製,即傳入的物件內包含的所有物件和所有物件中包含的所有物件……都必須要複製。

完全沒有效率。

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

所有主流面向物件語言都有這個問題。 

再見,封裝。

03 多型,倒塌的第三根支柱

多型是面向物件的三位一體中永遠被人拋棄的那一位。

就像是三人組中的Larry Fine。

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

並不是因為多型不好,而是因為實現多型並不需要面向物件語言。

介面也能實現多型,而且不需要面向物件的負擔。

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

所以,無需多言,我們可以告別面向物件的多型,去迎接基於介面的多型吧。

04 破碎的承諾

當然,面向物件在早期承諾了許多。而直到今天,這些承諾依然在教室裡、部落格上和網上資源中傳授給青澀的程式員們。

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

然後我發現被騙了。

再見,面向物件程式設計。

05 那該怎麼辦?

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

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

一朝被蛇咬十年怕井繩。

你懂的。

原文:

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

更多精彩


在公眾號後臺對話方塊輸入以下關鍵詞

檢視更多優質內容!


PPT | 報告 | 讀書 | 書單

Python | 機器學習 | 深度學習 | 神經網路

區塊鏈 | 揭秘 | 乾貨 | 數學

猜你想看

Q: 你還在面向物件程式設計嗎

歡迎留言與大家分享

覺得不錯,請把這篇文章分享給你的朋友

轉載 / 投稿請聯絡:baiyu@hzbook.com

更多精彩,請在後臺點選“歷史文章”檢視

贊(0)

分享創造快樂