當(dāng)前位置:首頁 > 公眾號精選 > 21ic電子網(wǎng)
[導(dǎo)讀]作為程序員,你是使用函數(shù)式編程還是面向?qū)ο缶幊谭绞剑?在本文中,擁有 10 多年軟件開發(fā)經(jīng)驗(yàn)的作者從面向?qū)ο缶幊痰娜筇匦浴^承、封裝、多態(tài)三大角度提出了自己的疑問,并深刻表示是時(shí)候和面向?qū)ο缶幊陶f再見了。 幾十年來我都在用面向?qū)ο蟮恼Z言編程。


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

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


幾十年來我都在用面向?qū)ο蟮恼Z言編程。我用過的第一個面向?qū)ο蟮恼Z言是 C++,后來是 Smalltalk,最后是 .NET 和 Java。
我曾經(jīng)對使用繼承、封裝和多態(tài)充滿熱情。它們是范式的三大支柱。
我渴望實(shí)現(xiàn)重用之美,并在這個令人興奮的新天地中享受前輩們積累的智慧。
想到將現(xiàn)實(shí)世界的一切映射到類中,使得整個世界都可以得到整齊的規(guī)劃,我無法抑制自己的興奮。
然而我大錯特錯了。
 01 
繼承,倒塌的第一根支柱
乍一看,繼承似乎是面向?qū)ο蠓妒降淖畲髢?yōu)勢。所有新手教程講解繼承時(shí)都會拿出最簡單的繼承的例子,而這個例子似乎很符合邏輯。
還在面向?qū)ο缶幊??是時(shí)候說再見了!
然后就是滿篇的重用了。甚至以后的一切都是重用了。
我囫圇吞下這一切,然后帶著新發(fā)現(xiàn)興沖沖地奔向世界了。
香蕉猴子叢林問題
帶著滿腔的信仰和解決問題的熱情,我開始構(gòu)建類的層次結(jié)構(gòu)然后寫代碼。似乎一切皆在掌控中。
我永遠(yuǎn)不會忘記我準(zhǔn)備從已有的類繼承并實(shí)現(xiàn)重用的那一天。那是我期待已久的時(shí)刻。
后來有了新的項(xiàng)目,我想起了另一個項(xiàng)目里我很喜歡的那個類。
沒問題,重用拯救一切。我只需要把那個類拿過來用就好了。
嗯……其實(shí)……不僅是那一個類。還得把父類也拿過來。但……應(yīng)該就可以了吧。
額……不對,似乎還需要父類的父類……還有……嗯,我們需要所有的祖先類。好吧好吧……搞定了。沒問題。
不錯。但編譯不過,怎么回事?哦我知道了……這個對象還需要另一個對象。所以那個也得拿過來。沒問題……
等等……我不僅需要那個對象,還需要那個對象的父類,和父類的父類,和……包含的所有對象的所有祖先……
唉……
Erlang 的創(chuàng)建者 JoeArmstrong 有句名言:
面向?qū)ο笳Z言的問題在于,它們依賴于特定的環(huán)境。你想要個香蕉,但拿到的卻是拿著香蕉的猩猩,乃至最后你擁有了整片叢林。
香蕉猴子叢林的解決方法
這個問題的解決方法是,不要把類層次建得那么深。但如果繼承是重用的關(guān)鍵,那么給繼承機(jī)制添加的任何限制都會限制重用。對吧?
沒錯。
那我們可憐的面向?qū)ο蟪绦騿T該怎么辦?指望一杯三聚氰胺奶維系我們的健康嗎?
答案就是:包含和委托(Contain and Delegate)。一會兒會詳細(xì)解釋。
菱形繼承問題
早晚你會遇到下面這種惡心的問題,有些語言甚至根本解決不了。
還在面向?qū)ο缶幊??是時(shí)候說再見了!
大多數(shù)面向?qū)ο笳Z言都不支持這種情況,盡管看上去似乎很符合邏輯。為什么面向?qū)ο笳Z言支持這種情況如此困難?
來看看下面的偽代碼:
    
Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
  function start() {
  }
}
Class Printer inherits from PoweredDevice {
  function start() {
  }
}
Class Copier inherits from ScannerPrinter {
}
注意 Scanner 和 Printer 類都實(shí)現(xiàn)了名為 start 方法。
那么問題來了,Copier繼承哪個start?是Scanner的還是Printer的?肯定不可能同時(shí)繼承啊。
菱形繼承的解決
解決方案很簡單:不要這樣做。
沒錯。大多數(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 類包含一個 Printer 實(shí)例和一個 Scanner 實(shí)例。然后將 start 函數(shù)委托給 Printer 類的實(shí)現(xiàn)。要委托給 Scanner 也很簡單。
這個問題是繼承這根支柱上的另一條裂縫。
脆弱的基類問題
好吧,那我盡量使用較淺的類層次結(jié)構(gòu),并保證里面沒有環(huán),這樣就不會出現(xiàn)菱形繼承了。
似乎一切都解決了。直到我們發(fā)現(xiàn)……
我前一天工作得好好的代碼今天出錯了!關(guān)鍵是,我沒有改任何代碼!
嗯也許是個 bug……但等等……的確有些改動……
但改動的不是我的代碼。似乎改動來自我繼承的那個類。
為什么基類的改動會破壞我的代碼?
原來是這樣……
看看下面這個基類(用Java寫的,但就算你不懂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ǎo)致別的東西出錯。 
這個類的接口上有兩個函數(shù):add() 和 addAll()。add() 函數(shù)負(fù)責(zé)添加一個元素,addAll() 函數(shù)會調(diào)用 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會維護(hù)一個count,記錄元素的個數(shù)。
我們來仔細(xì)看看這兩個類。
Array的add()給局部的ArrayList添加一個元素。
Array的addAll()針對每個元素調(diào)用局部的ArrayList的add方法。
ArrayCount的add()調(diào)用父類的add()然后增加count。
ArrayCount的addAll()調(diào)用父類的addAll()然后給count增加相當(dāng)于元素個數(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
  }
從基類的作者的角度來看,這個類實(shí)現(xiàn)的功能完全沒有變化。而且所有自動化測試也都通過來了。
但是基類的作者忘記了繼承的類。而繼承類的作者被錯誤吵醒了。
現(xiàn)在ArrayCount的addAll()調(diào)用父類的addAll(),后者在內(nèi)部調(diào)用add(),而add()被繼承類重載了。
因此,每次繼承類的add()被調(diào)用時(shí),count都會增加,然后在繼承類的addAll()被調(diào)用時(shí)再次增加。
count被增加了兩次。
既然會發(fā)生這種現(xiàn)象,那么繼承類的作者必須清楚基類是怎樣實(shí)現(xiàn)的。而且,基類的每個改動必須要通知所有繼承類的作者,因?yàn)檫@些改動可能會以不可預(yù)知的方式破壞繼承類。
唉!這個巨大的裂隙威脅到了整個繼承支柱的穩(wěn)定。
脆弱的基類的解決方法
這個問題還得要包含和委托來解決。
使用包含和委托,可以從白盒編程轉(zhuǎn)到黑盒編程。白盒編程的意思是說,寫繼承類時(shí)必須要了解基類的實(shí)現(xiàn)。
而黑盒編程可以完全無視基類的實(shí)現(xiàn),因?yàn)椴豢赡芡ㄟ^重載函數(shù)的方式向基類注入代碼。只需要關(guān)注接口即可。
這種趨勢太討厭了……
繼承本應(yīng)帶來最好用的重用。
在面向?qū)ο笳Z言中實(shí)現(xiàn)包含和委托并不容易。它們是為了繼承方便而設(shè)計(jì)的。
如果你和我一樣,你就會開始反思這個繼承了。但更重要的是,這些問題應(yīng)當(dāng)引起你對于通過層次結(jié)構(gòu)進(jìn)行分類的反思。
層次結(jié)構(gòu)的問題
每到一個新公司時(shí),我都要為在哪兒保存公司文檔(即員工手冊)而糾結(jié)。
是應(yīng)該建一個Documents文件夾,然后在里面建個Company呢?
還是應(yīng)該建個Company文件夾,然后在里面建個Documents呢?
兩者都可以。但哪個是正確的?哪個更好?
層次分類的思想是因?yàn)榛悾ǜ割悾└ㄓ?,繼承類(子類)更專用。沿著繼承鏈越往下走,概念就越專用(見上面的形狀層次)。
但如果父節(jié)點(diǎn)和子節(jié)點(diǎn)能隨意交換位置,那么顯然這種模型是有問題的。
層次結(jié)構(gòu)的解決
真正的問題出在……
層次分類是錯誤的。
那層次分類應(yīng)該用在哪里?
包含關(guān)系。
真實(shí)世界里有很多包含關(guān)系(或者叫做獨(dú)占關(guān)系)的層次結(jié)構(gòu)。
但你找不到層次分類。仔細(xì)想一下。面向?qū)ο蠓妒绞歉鶕?jù)充滿了各種對象的真實(shí)世界建立的。但它用錯了模型——層次分類在真實(shí)世界中沒有類比。
但真實(shí)世界里到處都是層次包含關(guān)系。層次包含關(guān)系的一個非常好的例子就是你的襪子。襪子放在裝襪子的抽屜里,然后抽屜包含在衣柜里,衣柜包含在臥室里,臥室包含在房子里,等等。 
硬盤上的目錄也是層次包含關(guān)系的另一個例子——它們包含文件。
那我們該怎樣分類呢?
仔細(xì)想一下公司文檔,就會發(fā)現(xiàn)其實(shí)放在哪兒都無所謂。我可以放在Documents目錄下或者放在Stuff目錄下也可以。
我選擇的分類法是標(biāo)簽。我給它加上不同的標(biāo)簽。
    
Document
Company
Handbook
標(biāo)簽是沒有順序或?qū)哟蔚模ㄟ@同時(shí)解決了菱形繼承問題)。
標(biāo)簽可以類比為接口,因?yàn)橥环菸臋n可以有多種類型。
但既然有了這么多裂縫,估計(jì)繼承的支柱已經(jīng)倒塌了。 
再見,繼承。
 02  
封裝,倒塌的第二根支柱 
乍一看,封裝似乎是面向?qū)ο缶幊痰牡诙蠛锰帯?/span>
對象狀態(tài)變量被保護(hù)起來防止外部訪問,即它們被封裝在對象內(nèi)部。
我們不需要再操心那些可能被不知道誰訪問的全局變量。
封裝是變量的保險(xiǎn)柜。
封裝太偉大了!
封裝萬歲…… 
直到你遇到了這個問題……
引用問題
為了提高效率,對象傳遞給函數(shù)時(shí)傳遞的是引用,而不是值。
也就是說,函數(shù)不會傳遞對象本身,而是傳遞指向?qū)ο蟮囊粋€引用或指針。
如果一個對象的引用被傳遞給另一個對象的構(gòu)造函數(shù),構(gòu)造函數(shù)就能將這個對象引用放到私有變量中,用封裝保護(hù)起來。
但這個傳遞的對象不是安全的!
為什么不是?因?yàn)槠渌a也可能擁有指向該對象的指針,比如調(diào)用構(gòu)造函數(shù)的那段代碼。它必須有指向?qū)ο蟮囊茫駝t沒辦法傳遞給構(gòu)造函數(shù)。
引用的解決
構(gòu)造函數(shù)必須要復(fù)制傳遞過來的對象。而且不能是淺復(fù)制,必須是深復(fù)制,即傳入的對象內(nèi)包含的所有對象和所有對象中包含的所有對象……都必須要復(fù)制。
完全沒有效率。
而且更糟糕的是,并非所有對象都能復(fù)制的。一些擁有操作系統(tǒng)資源的對象,最好的情況是復(fù)制無效,最糟糕的情況是根本不可能復(fù)制。
所有主流面向?qū)ο笳Z言都有這個問題。 
再見,封裝。
 03  
多態(tài),倒塌的第三根支柱
多態(tài)是面向?qū)ο蟮娜灰惑w中永遠(yuǎn)被人拋棄的那一位。
就像是三人組中的Larry Fine。
不管他們?nèi)ツ膬憾紩е?,但他永遠(yuǎn)是配角。
并不是因?yàn)槎鄳B(tài)不好,而是因?yàn)閷?shí)現(xiàn)多態(tài)并不需要面向?qū)ο笳Z言。
接口也能實(shí)現(xiàn)多態(tài),而且不需要面向?qū)ο蟮呢?fù)擔(dān)。
而且,接口也不會限制你能混入的不同行為的數(shù)目。 
所以,無需多言,我們可以告別面向?qū)ο蟮亩鄳B(tài),去迎接基于接口的多態(tài)吧。
 04  
破碎的承諾
當(dāng)然,面向?qū)ο笤谠缙诔兄Z了許多。而直到今天,這些承諾依然在教室里、博客上和網(wǎng)上資源中傳授給青澀的程序員們。
我花了多年才意識到面向?qū)ο蟮闹e言。以前我也曾經(jīng)青澀,曾經(jīng)輕信。
然后我發(fā)現(xiàn)被騙了。
再見,面向?qū)ο缶幊?/a>。
 05  
那該怎么辦?
去擁抱函數(shù)式編程吧。過去幾年我用得非常舒服。
但話說在先,我并沒有給你做出任何承諾。眼見為實(shí)。
一朝被蛇咬十年怕井繩。
你懂的!

-END-

來源:CSDN



推薦閱讀

【1】雷軍喜提第4家上市公司,又送出一公斤金磚

【2】溫故知新!六款簡單的開關(guān)電源電路設(shè)計(jì)

【3】終于整理齊了,電子工程師“設(shè)計(jì)錦囊”,你值得擁有!

【4】半導(dǎo)體行業(yè)的人都在關(guān)注這幾個公眾號

還在面向?qū)ο缶幊??是時(shí)候說再見了!

你和大牛工程師之間到底差了啥?
加入技術(shù)交流群,與高手面對面 
添加管理員微信

還在面向?qū)ο缶幊??是時(shí)候說再見了!

加入“中國電子網(wǎng)微信群”交流

還在面向?qū)ο缶幊??是時(shí)候說再見了!
具體加群詳情請戳
“中國電子網(wǎng)技術(shù)交流群” 

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

21ic電子網(wǎng)

掃描二維碼,關(guān)注更多精彩內(nèi)容

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉