面向?qū)ο缶幊?，再?jiàn)！

時(shí)間：2020-04-27 09:58:27

關(guān)鍵字：面向?qū)ο缶幊?/a> BSP 函數(shù) LEM

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]來(lái)源：CSDN知識(shí)庫(kù)? 作為程序員，你是使用函數(shù)式編程還是面向?qū)ο缶幊谭绞剑?在本文中，擁有 10 多年軟件開(kāi)發(fā)經(jīng)驗(yàn)的作者從面向?qū)ο缶幊痰娜筇匦浴^承、封裝、多態(tài)三大角度提出了自己的疑問(wèn)，并深刻表示是時(shí)候和面向?qū)ο缶幊陶f(shuō)再見(jiàn)了。幾十年來(lái)我都在用

來(lái)源：CSDN知識(shí)庫(kù)

作為程序員，你是使用函數(shù)式編程還是面向?qū)ο缶幊?/a>方式？

在本文中，擁有 10 多年軟件開(kāi)發(fā)經(jīng)驗(yàn)的作者從面向?qū)ο缶幊痰娜筇匦浴^承、封裝、多態(tài)三大角度提出了自己的疑問(wèn)，并深刻表示是時(shí)候和面向?qū)ο缶幊陶f(shuō)再見(jiàn)了。

幾十年來(lái)我都在用面向?qū)ο蟮恼Z(yǔ)言編程。我用過(guò)的第一個(gè)面向?qū)ο蟮恼Z(yǔ)言是 C++，后來(lái)是 Smalltalk，最后是 .NET 和 Java。

我曾經(jīng)對(duì)使用繼承、封裝和多態(tài)充滿(mǎn)熱情。它們是范式的三大支柱。

我渴望實(shí)現(xiàn)重用之美，并在這個(gè)令人興奮的新天地中享受前輩們積累的智慧。

想到將現(xiàn)實(shí)世界的一切映射到類(lèi)中，使得整個(gè)世界都可以得到整齊的規(guī)劃，我無(wú)法抑制自己的興奮。

然而我大錯(cuò)特錯(cuò)了。

繼承，倒塌的第一根支柱

乍一看，繼承似乎是面向?qū)ο蠓妒降淖畲髢?yōu)勢(shì)。所有新手教程講解繼承時(shí)都會(huì)拿出最簡(jiǎn)單的繼承的例子，而這個(gè)例子似乎很符合邏輯。

然后就是滿(mǎn)篇的重用了。甚至以后的一切都是重用了。

我囫圇吞下這一切，然后帶著新發(fā)現(xiàn)興沖沖地奔向世界了。

香蕉猴子叢林問(wèn)題

帶著滿(mǎn)腔的信仰和解決問(wèn)題的熱情，我開(kāi)始構(gòu)建類(lèi)的層次結(jié)構(gòu)然后寫(xiě)代碼。似乎一切皆在掌控中。

我永遠(yuǎn)不會(huì)忘記我準(zhǔn)備從已有的類(lèi)繼承并實(shí)現(xiàn)重用的那一天。那是我期待已久的時(shí)刻。

后來(lái)有了新的項(xiàng)目，我想起了另一個(gè)項(xiàng)目里我很喜歡的那個(gè)類(lèi)。

沒(méi)問(wèn)題，重用拯救一切。我只需要把那個(gè)類(lèi)拿過(guò)來(lái)用就好了。

嗯……其實(shí)……不僅是那一個(gè)類(lèi)。還得把父類(lèi)也拿過(guò)來(lái)。但……應(yīng)該就可以了吧。

額……不對(duì)，似乎還需要父類(lèi)的父類(lèi)……還有……嗯，我們需要所有的祖先類(lèi)。好吧好吧……搞定了。沒(méi)問(wèn)題。

不錯(cuò)。但編譯不過(guò)，怎么回事？哦我知道了……這個(gè)對(duì)象還需要另一個(gè)對(duì)象。所以那個(gè)也得拿過(guò)來(lái)。沒(méi)問(wèn)題……

等等……我不僅需要那個(gè)對(duì)象，還需要那個(gè)對(duì)象的父類(lèi)，和父類(lèi)的父類(lèi)，和……包含的所有對(duì)象的所有祖先……

唉……

Erlang 的創(chuàng)建者 JoeArmstrong 有句名言：

面向?qū)ο笳Z(yǔ)言的問(wèn)題在于，它們依賴(lài)于特定的環(huán)境。你想要個(gè)香蕉，但拿到的卻是拿著香蕉的猩猩，乃至最后你擁有了整片叢林。

香蕉猴子叢林的解決方法

這個(gè)問(wèn)題的解決方法是，不要把類(lèi)層次建得那么深。但如果繼承是重用的關(guān)鍵，那么給繼承機(jī)制添加的任何限制都會(huì)限制重用。對(duì)吧？

沒(méi)錯(cuò)。

那我們可憐的面向?qū)ο蟪绦騿T該怎么辦？指望一杯三聚氰胺奶維系我們的健康嗎？

答案就是：包含和委托（Contain and Delegate）。一會(huì)兒會(huì)詳細(xì)解釋。

菱形繼承問(wèn)題

早晚你會(huì)遇到下面這種惡心的問(wèn)題，有些語(yǔ)言甚至根本解決不了。

大多數(shù)面向?qū)ο笳Z(yǔ)言都不支持這種情況，盡管看上去似乎很符合邏輯。為什么面向?qū)ο笳Z(yǔ)言支持這種情況如此困難？

來(lái)看看下面的偽代碼：

    
     Class PoweredDevice {
     
}
     

     Class Scanner inherits from PoweredDevice {
     
  
     function start() {
     
  }
     
}
     

     Class Printer inherits from PoweredDevice {
     
  
     function start() {
     
  }
     
}
     

     Class Copier inherits from Scanner, Printer {
     
}

注意 Scanner 和 Printer 類(lèi)都實(shí)現(xiàn)了名為 start 方法。

那么問(wèn)題來(lái)了，Copier繼承哪個(gè)start？是Scanner的還是Printer的？肯定不可能同時(shí)繼承啊。

菱形繼承的解決

解決方案很簡(jiǎn)單：不要這樣做。

沒(méi)錯(cuò)。大多數(shù)面向?qū)ο蠖疾蛔屇氵@么干。

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

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

    
     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 類(lèi)包含一個(gè) Printer 實(shí)例和一個(gè) Scanner 實(shí)例。然后將 start 函數(shù)委托給 Printer 類(lèi)的實(shí)現(xiàn)。要委托給 Scanner 也很簡(jiǎn)單。

這個(gè)問(wèn)題是繼承這根支柱上的另一條裂縫。

脆弱的基類(lèi)問(wèn)題

好吧，那我盡量使用較淺的類(lèi)層次結(jié)構(gòu)，并保證里面沒(méi)有環(huán)，這樣就不會(huì)出現(xiàn)菱形繼承了。

似乎一切都解決了。直到我們發(fā)現(xiàn)……

我前一天工作得好好的代碼今天出錯(cuò)了！關(guān)鍵是，我沒(méi)有改任何代碼！

嗯也許是個(gè) bug……但等等……的確有些改動(dòng)……

但改動(dòng)的不是我的代碼。似乎改動(dòng)來(lái)自我繼承的那個(gè)類(lèi)。

為什么基類(lèi)的改動(dòng)會(huì)破壞我的代碼？

原來(lái)是這樣……

看看下面這個(gè)基類(lèi)（用Java寫(xiě)的，但就算你不懂Java，應(yīng)該也很容易看懂）：

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

重要提示： 注意加了注釋的那一行。稍后這行的改動(dòng)將會(huì)導(dǎo)致別的東西出錯(cuò)。

這個(gè)類(lèi)的接口上有兩個(gè)函數(shù)：add() 和 addAll()。add() 函數(shù)負(fù)責(zé)添加一個(gè)元素，addAll() 函數(shù)會(huì)調(diào)用 add 函數(shù)添加多個(gè)元素。

下面是繼承的類(lèi)：

    
     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類(lèi)是通用的Array類(lèi)的特化。兩者行為上的唯一區(qū)別就是ArrayCount會(huì)維護(hù)一個(gè)count，記錄元素的個(gè)數(shù)。

我們來(lái)仔細(xì)看看這兩個(gè)類(lèi)。

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

Array的addAll()針對(duì)每個(gè)元素調(diào)用局部的ArrayList的add方法。

ArrayCount的add()調(diào)用父類(lèi)的add()然后增加count。

ArrayCount的addAll()調(diào)用父類(lèi)的addAll()然后給count增加相當(dāng)于元素個(gè)數(shù)的數(shù)。

一切都很正常。

現(xiàn)在是出問(wèn)題的地方。基類(lèi)中加注釋的那行代碼現(xiàn)在改成這樣：

    
     public void addAll(Object elements[])
  {
     
    
     for (
     int i = 
     0; i < elements.length; ++i)
     
      
     add(elements[i]); 
     // this line was changed
     
  }

從基類(lèi)的作者的角度來(lái)看，這個(gè)類(lèi)實(shí)現(xiàn)的功能完全沒(méi)有變化。而且所有自動(dòng)化測(cè)試也都通過(guò)來(lái)了。

但是基類(lèi)的作者忘記了繼承的類(lèi)。而繼承類(lèi)的作者被錯(cuò)誤吵醒了。

現(xiàn)在ArrayCount的addAll()調(diào)用父類(lèi)的addAll()，后者在內(nèi)部調(diào)用add()，而add()被繼承類(lèi)重載了。

因此，每次繼承類(lèi)的add()被調(diào)用時(shí)，count都會(huì)增加，然后在繼承類(lèi)的addAll()被調(diào)用時(shí)再次增加。

count被增加了兩次。

既然會(huì)發(fā)生這種現(xiàn)象，那么繼承類(lèi)的作者必須清楚基類(lèi)是怎樣實(shí)現(xiàn)的。而且，基類(lèi)的每個(gè)改動(dòng)必須要通知所有繼承類(lèi)的作者，因?yàn)檫@些改動(dòng)可能會(huì)以不可預(yù)知的方式破壞繼承類(lèi)。

唉！這個(gè)巨大的裂隙威脅到了整個(gè)繼承支柱的穩(wěn)定。

脆弱的基類(lèi)的解決方法

這個(gè)問(wèn)題還得要包含和委托來(lái)解決。

使用包含和委托，可以從白盒編程轉(zhuǎn)到黑盒編程。白盒編程的意思是說(shuō)，寫(xiě)繼承類(lèi)時(shí)必須要了解基類(lèi)的實(shí)現(xiàn)。

而黑盒編程可以完全無(wú)視基類(lèi)的實(shí)現(xiàn)，因?yàn)椴豢赡芡ㄟ^(guò)重載函數(shù)的方式向基類(lèi)注入代碼。只需要關(guān)注接口即可。

這種趨勢(shì)太討厭了……

繼承本應(yīng)帶來(lái)最好用的重用。

在面向?qū)ο笳Z(yǔ)言中實(shí)現(xiàn)包含和委托并不容易。它們是為了繼承方便而設(shè)計(jì)的。

如果你和我一樣，你就會(huì)開(kāi)始反思這個(gè)繼承了。但更重要的是，這些問(wèn)題應(yīng)當(dāng)引起你對(duì)于通過(guò)層次結(jié)構(gòu)進(jìn)行分類(lèi)的反思。

層次結(jié)構(gòu)的問(wèn)題

每到一個(gè)新公司時(shí)，我都要為在哪兒保存公司文檔（即員工手冊(cè)）而糾結(jié)。

是應(yīng)該建一個(gè)Documents文件夾，然后在里面建個(gè)Company呢？

還是應(yīng)該建個(gè)Company文件夾，然后在里面建個(gè)Documents呢？

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

層次分類(lèi)的思想是因?yàn)榛?lèi)（父類(lèi)）更通用，繼承類(lèi)（子類(lèi)）更專(zhuān)用。沿著繼承鏈越往下走，概念就越專(zhuān)用（見(jiàn)上面的形狀層次）。

但如果父節(jié)點(diǎn)和子節(jié)點(diǎn)能隨意交換位置，那么顯然這種模型是有問(wèn)題的。

層次結(jié)構(gòu)的解決

真正的問(wèn)題出在……

層次分類(lèi)是錯(cuò)誤的。

那層次分類(lèi)應(yīng)該用在哪里？

包含關(guān)系。

真實(shí)世界里有很多包含關(guān)系（或者叫做獨(dú)占關(guān)系）的層次結(jié)構(gòu)。

但你找不到層次分類(lèi)。仔細(xì)想一下。面向?qū)ο蠓妒绞歉鶕?jù)充滿(mǎn)了各種對(duì)象的真實(shí)世界建立的。但它用錯(cuò)了模型——層次分類(lèi)在真實(shí)世界中沒(méi)有類(lèi)比。

但真實(shí)世界里到處都是層次包含關(guān)系。層次包含關(guān)系的一個(gè)非常好的例子就是你的襪子。襪子放在裝襪子的抽屜里，然后抽屜包含在衣柜里，衣柜包含在臥室里，臥室包含在房子里，等等。

硬盤(pán)上的目錄也是層次包含關(guān)系的另一個(gè)例子——它們包含文件。

那我們?cè)撛鯓臃诸?lèi)呢？

仔細(xì)想一下公司文檔，就會(huì)發(fā)現(xiàn)其實(shí)放在哪兒都無(wú)所謂。我可以放在Documents目錄下或者放在Stuff目錄下也可以。

我選擇的分類(lèi)法是標(biāo)簽。我給它加上不同的標(biāo)簽。

    
     Document
     
Company
     
Handbook

標(biāo)簽是沒(méi)有順序或?qū)哟蔚模ㄟ@同時(shí)解決了菱形繼承問(wèn)題）。

標(biāo)簽可以類(lèi)比為接口，因?yàn)橥环菸臋n可以有多種類(lèi)型。

但既然有了這么多裂縫，估計(jì)繼承的支柱已經(jīng)倒塌了。

再見(jiàn)，繼承。

封裝，倒塌的第二根支柱

乍一看，封裝似乎是面向?qū)ο缶幊痰牡诙蠛锰帯?/span>

對(duì)象狀態(tài)變量被保護(hù)起來(lái)防止外部訪問(wèn)，即它們被封裝在對(duì)象內(nèi)部。

我們不需要再操心那些可能被不知道誰(shuí)訪問(wèn)的全局變量。

封裝是變量的保險(xiǎn)柜。

封裝太偉大了！

封裝萬(wàn)歲……

直到你遇到了這個(gè)問(wèn)題……

引用問(wèn)題

為了提高效率，對(duì)象傳遞給函數(shù)時(shí)傳遞的是引用，而不是值。

也就是說(shuō)，函數(shù)不會(huì)傳遞對(duì)象本身，而是傳遞指向?qū)ο蟮囊粋€(gè)引用或指針。

如果一個(gè)對(duì)象的引用被傳遞給另一個(gè)對(duì)象的構(gòu)造函數(shù)，構(gòu)造函數(shù)就能將這個(gè)對(duì)象引用放到私有變量中，用封裝保護(hù)起來(lái)。

但這個(gè)傳遞的對(duì)象不是安全的！

為什么不是？因?yàn)槠渌a也可能擁有指向該對(duì)象的指針，比如調(diào)用構(gòu)造函數(shù)的那段代碼。它必須有指向?qū)ο蟮囊?，否則沒(méi)辦法傳遞給構(gòu)造函數(shù)。

引用的解決

構(gòu)造函數(shù)必須要復(fù)制傳遞過(guò)來(lái)的對(duì)象。而且不能是淺復(fù)制，必須是深復(fù)制，即傳入的對(duì)象內(nèi)包含的所有對(duì)象和所有對(duì)象中包含的所有對(duì)象……都必須要復(fù)制。

完全沒(méi)有效率。

而且更糟糕的是，并非所有對(duì)象都能復(fù)制的。一些擁有操作系統(tǒng)資源的對(duì)象，最好的情況是復(fù)制無(wú)效，最糟糕的情況是根本不可能復(fù)制。

所有主流面向?qū)ο笳Z(yǔ)言都有這個(gè)問(wèn)題。

再見(jiàn)，封裝。

多態(tài)，倒塌的第三根支柱

多態(tài)是面向?qū)ο蟮娜灰惑w中永遠(yuǎn)被人拋棄的那一位。

就像是三人組中的Larry Fine。

不管他們?nèi)ツ膬憾紩?huì)帶著他，但他永遠(yuǎn)是配角。

并不是因?yàn)槎鄳B(tài)不好，而是因?yàn)閷?shí)現(xiàn)多態(tài)并不需要面向?qū)ο笳Z(yǔ)言。

接口也能實(shí)現(xiàn)多態(tài)，而且不需要面向?qū)ο蟮呢?fù)擔(dān)。

而且，接口也不會(huì)限制你能混入的不同行為的數(shù)目。

所以，無(wú)需多言，我們可以告別面向?qū)ο蟮亩鄳B(tài)，去迎接基于接口的多態(tài)吧。

破碎的承諾

當(dāng)然，面向?qū)ο笤谠缙诔兄Z了許多。而直到今天，這些承諾依然在教室里、博客上和網(wǎng)上資源中傳授給青澀的程序員們。

我花了多年才意識(shí)到面向?qū)ο蟮闹e言。以前我也曾經(jīng)青澀，曾經(jīng)輕信。

然后我發(fā)現(xiàn)被騙了。

再見(jiàn)，面向?qū)ο缶幊獭?/span>

那該怎么辦？

去擁抱函數(shù)式編程吧。過(guò)去幾年我用得非常舒服。

但話說(shuō)在先，我并沒(méi)有給你做出任何承諾。眼見(jiàn)為實(shí)。

一朝被蛇咬十年怕井繩。

你懂的！

-END-

推薦閱讀

【01】嵌入式編程中的復(fù)雜指針的使用

【02】嵌入式編程必備之多方法測(cè)定程序運(yùn)行時(shí)間(經(jīng)驗(yàn)篇)

【03】RT-Thread 面向?qū)ο缶幊?/a>思路淺析

【04】若想成為一名Linux下編程高手，必須能對(duì)各種系統(tǒng)調(diào)用有透徹的了解

【05】NASA頂級(jí)程序員是如何編程的？其實(shí)有十大準(zhǔn)則

免責(zé)聲明：整理文章為傳播相關(guān)技術(shù)，版權(quán)歸原作者所有，如有侵權(quán)，請(qǐng)聯(lián)系刪除

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！