20 世紀(jì) 60 年代,,編程遇到了一個(gè)大問題:計(jì)算機(jī)還沒有那么強(qiáng)大,需要以某種方式平衡數(shù)據(jù)結(jié)構(gòu)和程序之間的能力,。
這意味著,,如果你有大量數(shù)據(jù),,那么不將計(jì)算機(jī)推向極限就無法充分利用這些數(shù)據(jù),。另外,,如果你需要做很多事情,那么你就不能使用過多的數(shù)據(jù),,否則計(jì)算機(jī)將會(huì)一直運(yùn)行下去,。
接下來到了 1966、1967 年,,Alan Kay 從理論上證明可以使用封裝的微型計(jì)算機(jī),。這些微型計(jì)算機(jī)不共享數(shù)據(jù),而是通過消息傳遞進(jìn)行通信,。這樣就可以更加經(jīng)濟(jì)地使用計(jì)算資源,。
盡管這個(gè)想法很巧妙,但直到 1981 年,,面向?qū)ο缶幊滩懦蔀橹髁?。在那之后,它就沒有停止過吸引新的和經(jīng)驗(yàn)豐富的軟件開發(fā)者,。面向?qū)ο蟮某绦騿T市場一如既往地忙碌,。
但是在最近幾年中,這種已有幾十年歷史的編程范式受到越來越多的批評(píng),。難道是在面向?qū)ο缶幊檀笮衅涞?40 年之后,技術(shù)已經(jīng)超越了這種范式,?
函數(shù)和數(shù)據(jù)耦合
面向?qū)ο缶幊痰闹饕枷敕浅:唵危簢L試將一個(gè)功能強(qiáng)大的程序整體分解為功能同樣強(qiáng)大的多個(gè)部分,。這樣就可以將一些數(shù)據(jù)和那些只在相關(guān)數(shù)據(jù)上使用的函數(shù)耦合起來。
注意,,這僅涵蓋封裝的概念,。也就是說,位于對象內(nèi)部的數(shù)據(jù)和函數(shù)對于外部是不可見的,。我們只能通過消息(通常通過 getter 和 setter 函數(shù))與對象的內(nèi)容進(jìn)行交互,。
繼承性和多態(tài)性并沒有包含在最初的設(shè)計(jì)想法中,,但是對于現(xiàn)在的面向?qū)ο缶幊潭允潜匦璧摹@^承基本上意味著開發(fā)者可以定義具有其父類所有屬性的子類,。直到 1976 年,,即面向?qū)ο蟮某绦蛟O(shè)計(jì)的概念問世十年之后,繼承性才被引入,。
又過了十年,,多態(tài)性才進(jìn)入面向?qū)ο蟮木幊獭:唵蝸碇v,,這意味著某種方法或?qū)ο罂梢杂米銎渌椒ɑ驅(qū)ο蟮哪0?。從某種意義上說,多態(tài)性是繼承性的泛化,,因?yàn)椴⒉皇窃挤椒ɑ驅(qū)ο蟮乃袑傩远夹枰獋鬏數(shù)叫聦?shí)體,。相反,你還可以選擇重寫一些屬性,。
多態(tài)性的特殊之處在于,,即使兩個(gè)實(shí)體在源代碼中互相依賴,被調(diào)用實(shí)體的工作方式也更像插件,。這使得開發(fā)人員的工作變得輕松,,因?yàn)樗麄儾槐負(fù)?dān)心運(yùn)行時(shí)的依賴關(guān)系。
值得一提的是,,繼承性和多態(tài)性并不是面向?qū)ο缶幊趟赜械?。真正的區(qū)別在于封裝數(shù)據(jù)及其包含的方法。在計(jì)算資源比今天稀缺得多的時(shí)代,,這是一個(gè)天才的想法,。
面向?qū)ο缶幊讨械?5 大問題
面向?qū)ο蟮木幊桃唤?jīng)問世,便改變了開發(fā)人員看待代碼的方式,。20 世紀(jì) 80 年代以前,,過程式編程非常面向機(jī)器。開發(fā)人員需要非常了解計(jì)算機(jī)的工作原理才能編寫好的代碼,。
通過封裝數(shù)據(jù)和其他方法,,面向?qū)ο蟮木幊淌管浖_發(fā)更加以人為中心,符合人類的直覺,。比如,,方法 drive() 屬于 car 數(shù)據(jù)組,而不是 teddybear 組,。之后出現(xiàn)的繼承性也很直觀,。比如,現(xiàn)代汽車(Hyundai)是汽車的一個(gè)子類,并且具有相同的屬性,,但 PooTheBear 不是,,這樣很好理解。
香蕉猴子叢林問題
想象一下,,你正在設(shè)置一個(gè)新程序,,并且正在考慮設(shè)計(jì)一個(gè)新類。然后,,你回想起為另一個(gè)項(xiàng)目創(chuàng)建的簡潔的小類,,發(fā)現(xiàn)其對正在進(jìn)行的工作很合適。
沒問題,,你可以將以前項(xiàng)目中的類在新項(xiàng)目中復(fù)用,。
這里有一個(gè)問題:這個(gè)類可能是另一個(gè)類的子類,因此你需要將它的父類也包含在內(nèi),。然后你會(huì)發(fā)現(xiàn),,這個(gè)父類可能也是另一個(gè)類的子類,以此類推,,最后要面對一堆代碼,。
Erlang 的創(chuàng)建者 Joe Armstrong 曾有一句名言:「面向?qū)ο笳Z言的問題在于,它們自帶其自身周圍的所有隱式環(huán)境,。你想要香蕉,,但是得到的卻是拿著香蕉的大猩猩和整個(gè)叢林?!?/p>
這幾乎可以說明一切,。復(fù)用類是可以的,實(shí)際上這可能是面向?qū)ο缶幊痰闹饕獌?yōu)點(diǎn),,但不要將其發(fā)揮到極致,。有時(shí)你應(yīng)該建立一個(gè)新的類,而不是添加大量依賴項(xiàng),。
脆弱的基類問題
想象一下,,如果你已經(jīng)成功地將另一個(gè)項(xiàng)目中的類復(fù)用于新的代碼,那么如果基類發(fā)生變化會(huì)怎樣,?
這可能會(huì)破壞你整個(gè)新項(xiàng)目的代碼,,即使你可能什么也沒做。一旦有人更改了基類中的一個(gè)細(xì)節(jié),,而這一點(diǎn)又對你的項(xiàng)目至關(guān)重要,,那么這種影響將是非常大并且突然的。
使用繼承的次數(shù)越多,,潛在的維護(hù)工作就越多。因此,即使在短期內(nèi)復(fù)用代碼非常有效,,但從長遠(yuǎn)來看,,它可能讓你付出一定的代價(jià)。
菱形繼承問題
利用繼承可以將一類中的屬性傳遞給其他類,。但是,,如果你想混合兩個(gè)不同類的屬性怎么辦?
沒錯(cuò),,這無法完成,,至少常規(guī)的方法都不行。以 Copier 類為例(在此引用以下鏈接文章中的例子:https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53),,Copier 將掃描文件的內(nèi)容并將其打印在白紙上,。那么它應(yīng)該是 Scanner 還是 Printer 的子類?
這個(gè)問題根本沒有完美的答案,。即使這個(gè)問題不會(huì)破壞你的代碼,,但它經(jīng)常出現(xiàn),會(huì)讓人很沮喪,。
層級(jí)問題
在菱形繼承問題中,,Copier 是哪個(gè)類的子類是問題的關(guān)鍵所在。但或許有個(gè)投機(jī)取巧的方案:假設(shè) Copier 是父類,,Scanner 和 Printer 是僅繼承屬性子集的子類,,那么問題就解決了。
但如果你的 Copier 是黑白的,,而 Printer 也能夠處理彩色,,那怎么辦?從這個(gè)意義上說,,Printer 不是 Copier 的一種泛化嗎,?如果 Printer 連接了 WiFi,而 Copier 沒有呢,?
類上堆積的屬性越多,,建立適當(dāng)?shù)膶哟谓Y(jié)構(gòu)就越困難。在你所處理的屬性集群中,,Copier 共享了 Printer 的一些屬性,,但不是全部屬性,反之亦然,。在大型復(fù)雜項(xiàng)目中,,層次結(jié)構(gòu)的問題會(huì)導(dǎo)致很大的混亂。
引用問題
你可能會(huì)想到進(jìn)行沒有層次結(jié)構(gòu)的面向?qū)ο缶幊?。我們可以使用屬性集群,,并根?jù)需要繼承,、擴(kuò)展或重寫屬性。也許這有點(diǎn)混亂,,但這將是對當(dāng)前問題的準(zhǔn)確表示,。
這里只存在一個(gè)問題:封裝的全部目的是使數(shù)據(jù)片段彼此之間保持安全,從而使計(jì)算效率更高,,但沒有嚴(yán)格的層次結(jié)構(gòu),,這是行不通的。
假設(shè)一個(gè)對象 A 通過與另一個(gè)對象 B 交互來覆蓋層次結(jié)構(gòu),,會(huì)發(fā)生什么情況,?其他關(guān)系的情況并不重要,但當(dāng) B 不是 A 的直接父類時(shí),,A 必須包含 B 的全部私有引用,,否則,它們將無法交互,。
但是,,如果 A 包含 B 的子類也具有的信息,那么就可以在多個(gè)位置修改該信息,。因此,,有關(guān) B 的信息已經(jīng)不再安全,并且封裝已經(jīng)被破壞,。
盡管許多面向?qū)ο蟮某绦騿T都使用這種架構(gòu)來構(gòu)建程序,,但這并不是面向?qū)ο缶幊蹋皇且粓F(tuán)糟,。
單一范式存在的風(fēng)險(xiǎn)
以上 5 個(gè)問題的共同點(diǎn)是它們都存在不合適的繼承,。由于繼承沒有包含在面向?qū)ο缶幊痰脑夹问街校赃@些問題可能不能稱為面向?qū)ο蟊旧淼膯栴},。
但是也并不是只有面向?qū)ο缶幊虝?huì)被夸大,。在純粹的函數(shù)式編程中,處理用戶的輸入或在屏幕上輸出消息極其困難,。對此,,面向?qū)ο蠡蛎嫦蜻^程編程會(huì)好很多。
但仍然有一些開發(fā)人員試圖將這些東西用純函數(shù)的方式實(shí)現(xiàn),,并且編寫幾十行沒人能看懂的代碼,。而使用另一種范式就能夠輕松地將代碼簡化為幾行可讀的代碼。
毫無疑問,,函數(shù)式編程正在得到更多關(guān)注,,而面向?qū)ο缶幊探鼛啄暝獾揭恍┰嵅 A私庑碌木幊谭妒讲⒃谶m當(dāng)?shù)臅r(shí)候使用它們是很有意義的,。無論哪種編程范式,,都不需要只遵循一種,,在適當(dāng)?shù)臅r(shí)候使用不同的編程范式才能更好地解決問題。
面向?qū)ο缶幊陶娴囊蝗〈藛幔?/strong>
面對越來越多的問題,,函數(shù)式編程可能是更有效的一種選擇,。數(shù)據(jù)分析、機(jī)器學(xué)習(xí),、并行編程,這些領(lǐng)域你投入的越多,,你就會(huì)越喜歡函數(shù)式編程,。
但是目前面向?qū)ο箝_發(fā)的程序員的崗位需求量依然比函數(shù)式編程開發(fā)程序員多得多。但是這也并不意味著你不能成為后者,,函數(shù)式編程開發(fā)的程序員目前仍然比較稀缺,。
最有可能的情況是,面向?qū)ο蟮木幊虒?huì)繼續(xù)存在十年左右,。當(dāng)然,,選擇相對前衛(wèi)的方式是好的,但這并不意味著你應(yīng)該放棄面向?qū)ο缶幊?。所以在接下來的幾年中,,不要完全放棄它,但至少確保它不是你唯一掌握的程序設(shè)計(jì)方式,。