20 世紀 60 年代，編程遇到了一個大問題：計算機還沒有那么強大，需要以某種方式平衡資料結構和程式之間的能力，

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

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

盡管這個想法很巧妙，但直到 1981 年，面向物件編程才成為主流，在那之后，它就沒有停止過吸引新的和經驗豐富的軟體開發者，面向物件的程式員市場一如既往地忙碌，

但是在最近幾年中，這種已有幾十年歷史的編程范式受到越來越多的批評，難道是在面向物件編程大行其道 40 年之后，技術已經超越了這種范式？

函式和資料耦合

面向物件編程的主要思想非常簡單：嘗試將一個功能強大的程式整體分解為功能同樣強大的多個部分，這樣就可以將一些資料和那些只在相關資料上使用的函式耦合起來，

注意，這僅涵蓋封裝的概念，也就是說，位于物件內部的資料和函式對于外部是不可見的，我們只能通過訊息（通常通過 getter 和 setter 函式）與物件的內容進行互動，

繼承性和多型性并沒有包含在最初的設計想法中，但是對于現在的面向物件編程而言是必需的，繼承基本上意味著開發者可以定義具有其父類所有屬性的子類，直到 1976 年，即面向物件的程式設計的概念問世十年之后，繼承性才被引入，

又過了十年，多型性才進入面向物件的編程，簡單來講，這意味著某種方法或物件可以用做其他方法或物件的模板，從某種意義上說，多型性是繼承性的泛化，因為并不是原始方法或物件的所有屬性都需要傳輸到新物體，相反，你還可以選擇重寫一些屬性，

多型性的特殊之處在于，即使兩個物體在源代碼中互相依賴，被呼叫物體的作業方式也更像插件，這使得開發人員的作業變得輕松，因為他們不必擔心運行時的依賴關系，

值得一提的是，繼承性和多型性并不是面向物件編程所特有的，真正的區別在于封裝資料及其包含的方法，在計算資源比今天稀缺得多的時代，這是一個天才的想法，

面向物件編程中的 5 大問題

面向物件的編程一經問世，便改變了開發人員看待代碼的方式，20 世紀 80 年代以前，程序式編程非常面向機器，開發人員需要非常了解計算機的作業原理才能撰寫好的代碼，

通過封裝資料和其他方法，面向物件的編程使軟體開發更加以人為中心，符合人類的直覺，比如，方法 drive() 屬于 car 資料組，而不是 teddybear 組，之后出現的繼承性也很直觀，比如，現代汽車（Hyundai）是汽車的一個子類，并且具有相同的屬性，但 PooTheBear 不是，這樣很好理解，

香蕉猴子叢林問題

想象一下，你正在設定一個新程式，并且正在考慮設計一個新類，然后，你回想起為另一個專案創建的簡潔的小類，發現其對正在進行的作業很合適，

沒問題，你可以將以前專案中的類在新專案中復用，

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

Erlang 的創建者 Joe Armstrong 曾有一句名言：「面向物件語言的問題在于，它們自帶其自身周圍的所有隱式環境，你想要香蕉，但是得到的卻是拿著香蕉的大猩猩和整個叢林，」

這幾乎可以說明一切，復用類是可以的，實際上這可能是面向物件編程的主要優點，但不要將其發揮到極致，有時你應該建立一個新的類，而不是添加大量依賴項，

脆弱的基類問題

想象一下，如果你已經成功地將另一個專案中的類復用于新的代碼，那么如果基類發生變化會怎樣？

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

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

菱形繼承問題

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

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

這個問題根本沒有完美的答案，即使這個問題不會破壞你的代碼，但它經常出現，會讓人很沮喪，

層級問題

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

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

類上堆積的屬性越多，建立適當的層次結構就越困難，在你所處理的屬性集群中，Copier 共享了 Printer 的一些屬性，但不是全部屬性，反之亦然，在大型復雜專案中，層次結構的問題會導致很大的混亂，

參考問題

你可能會想到進行沒有層次結構的面向物件編程，我們可以使用屬性集群，并根據需要繼承、擴展或重寫屬性，也許這有點混亂，但這將是對當前問題的準確表示，

這里只存在一個問題：封裝的全部目的是使資料片段彼此之間保持安全，從而使計算效率更高，但沒有嚴格的層次結構，這是行不通的，

假設一個物件 A 通過與另一個物件 B 互動來覆寫層次結構，會發生什么情況？其他關系的情況并不重要，但當 B 不是 A 的直接父類時，A 必須包含 B 的全部私有參考，否則，它們將無法互動，

但是，如果 A 包含 B 的子類也具有的資訊，那么就可以在多個位置修改該資訊，因此，有關 B 的資訊已經不再安全，并且封裝已經被破壞，

盡管許多面向物件的程式員都使用這種架構來構建程式，但這并不是面向物件編程，只是一團糟，

單一范式存在的風險

以上 5 個問題的共同點是它們都存在不合適的繼承，由于繼承沒有包含在面向物件編程的原始形式中，所以這些問題可能不能稱為面向物件本身的問題，

但是也并不是只有面向物件編程會被夸大，在純粹的函式式編程中，處理用戶的輸入或在螢屏上輸出訊息極其困難，對此，面向物件或面向程序編程會好很多，

但仍然有一些開發人員試圖將這些東西用純函式的方式實作，并且撰寫幾十行沒人能看懂的代碼，而使用另一種范式就能夠輕松地將代碼簡化為幾行可讀的代碼，

毫無疑問，函式式編程正在得到更多關注，而面向物件編程近幾年遭到一些詬病，了解新的編程范式并在適當的時候使用它們是很有意義的，無論哪種編程范式，都不需要只遵循一種，在適當的時候使用不同的編程范式才能更好地解決問題，

面向物件編程真的要被取代了嗎？

面對越來越多的問題，函式式編程可能是更有效的一種選擇，資料分析、機器學習、并行編程，這些領域你投入的越多，你就會越喜歡函式式編程，

但是目前面向物件開發的程式員的崗位需求量依然比函式式編程開發程式員多得多，但是這也并不意味著你不能成為后者，函式式編程開發的程式員目前仍然比較稀缺，

最有可能的情況是，面向物件的編程將會繼續存在十年左右，當然，選擇相對前衛的方式是好的，但這并不意味著你應該放棄面向物件編程，所以在接下來的幾年中，不要完全放棄它，但至少確保它不是你唯一掌握的程式設計方式，

推薦閱讀：

為什么阿里巴巴的程式員成長速度這么快，看完他們的內部資料我頓悟了

原來優秀程式員簡歷都是這么寫的，你學會你也可以進大廠！【附阿里p6簡歷分享】

阿里二面遭調優爆錘，閉關13天啃透這本性能實戰手冊，35K成功入職美團

作者親談《阿里巴巴Java開發手冊》背后的故事；附阿里內部資料分享，

看完三件事??

如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

1. 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力，

2. 關注公眾號 『 Java斗帝 』，不定期分享原創知識，

3. 同時可以期待后續文章ing🚀