面向?qū)ο缶幊桃蝗〈藛幔棵嫦驅(qū)ο缶幊讨械?大問題

20 世紀 60 年代，編程遇到了一個大問題：計算機還沒有那么強大，需要以某種方式平衡數(shù)據(jù)結(jié)構(gòu)和程序之間的能力。

這意味著，如果你有大量數(shù)據(jù)，那么不將計算機推向極限就無法充分利用這些數(shù)據(jù)。另外，如果你需要做很多事情，那么你就不能使用過多的數(shù)據(jù)，否則計算機將會一直運行下去。

接下來到了 1966、1967 年，Alan Kay 從理論上證明可以使用封裝的微型計算機。這些微型計算機不共享數(shù)據(jù)，而是通過消息傳遞進行通信。這樣就可以更加經(jīng)濟地使用計算資源。

盡管這個想法很巧妙，但直到 1981 年，面向?qū)ο缶幊滩懦蔀橹髁?。在那之后，它就沒有停止過吸引新的和經(jīng)驗豐富的軟件開發(fā)者。面向?qū)ο蟮?a href="http://wenjunhu.com/v/tag/1730/" target="_blank">程序員市場一如既往地忙碌。

但是在最近幾年中，這種已有幾十年歷史的編程范式受到越來越多的批評。難道是在面向?qū)ο缶幊檀笮衅涞?40 年之后，技術(shù)已經(jīng)超越了這種范式？

函數(shù)和數(shù)據(jù)耦合

面向?qū)ο缶幊痰闹饕枷敕浅：唵危簢L試將一個功能強大的程序整體分解為功能同樣強大的多個部分。這樣就可以將一些數(shù)據(jù)和那些只在相關(guān)數(shù)據(jù)上使用的函數(shù)耦合起來。

注意，這僅涵蓋封裝的概念。也就是說，位于對象內(nèi)部的數(shù)據(jù)和函數(shù)對于外部是不可見的。我們只能通過消息（通常通過 getter 和 setter 函數(shù)）與對象的內(nèi)容進行交互。

繼承性和多態(tài)性并沒有包含在最初的設(shè)計想法中，但是對于現(xiàn)在的面向?qū)ο缶幊潭允潜匦璧摹＠^承基本上意味著開發(fā)者可以定義具有其父類所有屬性的子類。直到 1976 年，即面向?qū)ο蟮某绦蛟O(shè)計的概念問世十年之后，繼承性才被引入。

又過了十年，多態(tài)性才進入面向?qū)ο蟮木幊?。簡單來講，這意味著某種方法或?qū)ο罂梢杂米銎渌椒ɑ驅(qū)ο蟮哪０濉哪撤N意義上說，多態(tài)性是繼承性的泛化，因為并不是原始方法或?qū)ο蟮乃袑傩远夹枰獋鬏數(shù)叫聦嶓w。相反，你還可以選擇重寫一些屬性。

多態(tài)性的特殊之處在于，即使兩個實體在源代碼中互相依賴，被調(diào)用實體的工作方式也更像插件。這使得開發(fā)人員的工作變得輕松，因為他們不必擔心運行時的依賴關(guān)系。

值得一提的是，繼承性和多態(tài)性并不是面向?qū)ο缶幊趟赜械摹Ｕ嬲膮^(qū)別在于封裝數(shù)據(jù)及其包含的方法。在計算資源比今天稀缺得多的時代，這是一個天才的想法。

面向?qū)ο缶幊讨械?5 大問題

面向?qū)ο蟮木幊桃唤?jīng)問世，便改變了開發(fā)人員看待代碼的方式。20 世紀 80 年代以前，過程式編程非常面向機器。開發(fā)人員需要非常了解計算機的工作原理才能編寫好的代碼。

通過封裝數(shù)據(jù)和其他方法，面向?qū)ο蟮木幊淌管浖_發(fā)更加以人為中心，符合人類的直覺。比如，方法 drive（） 屬于 car 數(shù)據(jù)組，而不是 teddybear 組。之后出現(xiàn)的繼承性也很直觀。比如，現(xiàn)代汽車（Hyundai）是汽車的一個子類，并且具有相同的屬性，但 PooTheBear 不是，這樣很好理解。

香蕉猴子叢林問題

想象一下，你正在設(shè)置一個新程序，并且正在考慮設(shè)計一個新類。然后，你回想起為另一個項目創(chuàng)建的簡潔的小類，發(fā)現(xiàn)其對正在進行的工作很合適。

沒問題，你可以將以前項目中的類在新項目中復用。

這里有一個問題：這個類可能是另一個類的子類，因此你需要將它的父類也包含在內(nèi)。然后你會發(fā)現(xiàn)，這個父類可能也是另一個類的子類，以此類推，最后要面對一堆代碼。

Erlang 的創(chuàng)建者 Joe Armstrong 曾有一句名言：「面向?qū)ο笳Z言的問題在于，它們自帶其自身周圍的所有隱式環(huán)境。你想要香蕉，但是得到的卻是拿著香蕉的大猩猩和整個叢林?！?/p>

這幾乎可以說明一切。復用類是可以的，實際上這可能是面向?qū)ο缶幊痰闹饕獌?yōu)點，但不要將其發(fā)揮到極致。有時你應該建立一個新的類，而不是添加大量依賴項。

脆弱的基類問題

想象一下，如果你已經(jīng)成功地將另一個項目中的類復用于新的代碼，那么如果基類發(fā)生變化會怎樣？

這可能會破壞你整個新項目的代碼，即使你可能什么也沒做。一旦有人更改了基類中的一個細節(jié)，而這一點又對你的項目至關(guān)重要，那么這種影響將是非常大并且突然的。

使用繼承的次數(shù)越多，潛在的維護工作就越多。因此，即使在短期內(nèi)復用代碼非常有效，但從長遠來看，它可能讓你付出一定的代價。

菱形繼承問題

利用繼承可以將一類中的屬性傳遞給其他類。但是，如果你想混合兩個不同類的屬性怎么辦？

沒錯，這無法完成，至少常規(guī)的方法都不行。以 Copier 類為例（在此引用以下鏈接文章中的例子：https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53），Copier 將掃描文件的內(nèi)容并將其打印在白紙上。那么它應該是 Scanner 還是 Printer 的子類？

這個問題根本沒有完美的答案。即使這個問題不會破壞你的代碼，但它經(jīng)常出現(xiàn)，會讓人很沮喪。

層級問題

在菱形繼承問題中，Copier 是哪個類的子類是問題的關(guān)鍵所在。但或許有個投機取巧的方案：假設(shè) Copier 是父類，Scanner 和 Printer 是僅繼承屬性子集的子類，那么問題就解決了。

但如果你的 Copier 是黑白的，而 Printer 也能夠處理彩色，那怎么辦？從這個意義上說，Printer 不是 Copier 的一種泛化嗎？如果 Printer 連接了 WiFi，而 Copier 沒有呢？

類上堆積的屬性越多，建立適當?shù)膶哟谓Y(jié)構(gòu)就越困難。在你所處理的屬性集群中，Copier 共享了 Printer 的一些屬性，但不是全部屬性，反之亦然。在大型復雜項目中，層次結(jié)構(gòu)的問題會導致很大的混亂。

引用問題

你可能會想到進行沒有層次結(jié)構(gòu)的面向?qū)ο缶幊?。我們可以使用屬性集群，并根?jù)需要繼承、擴展或重寫屬性。也許這有點混亂，但這將是對當前問題的準確表示。

這里只存在一個問題：封裝的全部目的是使數(shù)據(jù)片段彼此之間保持安全，從而使計算效率更高，但沒有嚴格的層次結(jié)構(gòu)，這是行不通的。

假設(shè)一個對象 A 通過與另一個對象 B 交互來覆蓋層次結(jié)構(gòu)，會發(fā)生什么情況？其他關(guān)系的情況并不重要，但當 B 不是 A 的直接父類時，A 必須包含 B 的全部私有引用，否則，它們將無法交互。

但是，如果 A 包含 B 的子類也具有的信息，那么就可以在多個位置修改該信息。因此，有關(guān) B 的信息已經(jīng)不再安全，并且封裝已經(jīng)被破壞。

盡管許多面向?qū)ο蟮某绦騿T都使用這種架構(gòu)來構(gòu)建程序，但這并不是面向?qū)ο缶幊蹋皇且粓F糟。

單一范式存在的風險

以上 5 個問題的共同點是它們都存在不合適的繼承。由于繼承沒有包含在面向?qū)ο缶幊痰脑夹问街?，所以這些問題可能不能稱為面向?qū)ο蟊旧淼膯栴}。

但是也并不是只有面向?qū)ο缶幊虝豢浯?。在純粹的函?shù)式編程中，處理用戶的輸入或在屏幕上輸出消息極其困難。對此，面向?qū)ο蠡蛎嫦蜻^程編程會好很多。

但仍然有一些開發(fā)人員試圖將這些東西用純函數(shù)的方式實現(xiàn)，并且編寫幾十行沒人能看懂的代碼。而使用另一種范式就能夠輕松地將代碼簡化為幾行可讀的代碼。

毫無疑問，函數(shù)式編程正在得到更多關(guān)注，而面向?qū)ο缶幊探鼛啄暝獾揭恍┰嵅?。了解新的編程范式并在適當?shù)臅r候使用它們是很有意義的。無論哪種編程范式，都不需要只遵循一種，在適當?shù)臅r候使用不同的編程范式才能更好地解決問題。

面向?qū)ο缶幊陶娴囊蝗〈藛幔?/strong>