一切皆物件的口號顯然有點過了，但也不至於說走了多少彎路。這個問題跟「子型別（subtyping）是不是錯誤（ill-defined）的東西？」有點類似，就是程式設計師突然發現工具箱裡面有些工具沒了的話好像也沒關係，就開始懷疑它們是不是多餘的或錯誤的設計。OOP是個模糊的概念，它不僅僅指程式語言的那些特性，OOP之前必須先OOD （Object Oriented Design），不可能脫離OOD談OOP，如果只談概念，我們來看看：封裝：到底什麼是封裝？私有方法？那 Haskell 只匯出 Smart Constructors 算不算？繼承：OCaml module include 算不算？Typeclass hierarchy 算不算？多型：引數化多型也叫多型啊！如何才能劃出一條清晰的邊線界定OOP？物件內部狀態？這可就麻煩大了，所有非純函數語言程式設計都不可能完全避開內部狀態。如果你就是要原教旨 Pure FP 大法好？那……你開心就好：type MonadStackHell a b c = AppT (MaybeT (ReaderT a (StateT b IO))) c不要跟我提Extensible effects，既然Haskell都只能做到這種地步，為什麼它就不算走彎路？有些人不爽的地方可能在於，資料和行為是兩個不同的維度，而現有的OOP語言都把資料和行為繫結到了一起，不得不用 Extensible Visitor Pattern 繞彎。可這本身就是難解之題，Haskell 裡面雖然可以很方便地用 Typeclass 擴充套件方法，但新增新的資料卻成了問題。Data types à la carte 那種方式雖然可以無限擴充套件資料，但卻增加了轉型的執行時開銷，魚和熊掌不可兼得，OOP 語言選擇了另一條路，但子型別虛擬函式又會增加方法呼叫的執行時開銷。（我也不提 Object Algebras 只從程式語言角度思考就進入了死衚衕，我們要從OOD的角度看。在設計時自然說 A student is a Person，繼承了Person的屬性和方法，Haskell不支援Record繼承，難道在設計時也說Student包含一個Person？然後白板上 Functor、MonadTrans、Constraints 滿天飛？這樣看將 Subtying 和 Inheritance 捆綁在一起還真是非常貼心，要是隻說Student是Person的子類還不夠，還要加一句Person有的ABCD介面Student都繼承實現，那就太囉嗦了 。物件思維方式顯然更易於描述現實中的大部分業務模型。它有它的侷限性，但離氾濫還遠著呢，我看到更多的是很多程式設計師根本不懂面向物件設計，甚至根本就沒有 Design 這一步，從這方面來講，不但不算是彎路，甚至還應該繼續大力推進。問題的關鍵並不在於OOP，而在於錯誤的OOD。如果OOD本身就是錯的，那麼正確的又是什麼？我覺得現在我們還不能完美回答這個問題，有一個詞呼之欲出： Language Oriented Design，但是我們還有很多路要走，而且我很懷疑有些業務邏輯天生更適合用OOD描述，換成LOD只不過是重新發明一個OO DSL而已。

在面向物件程式設計正規化成為主流的今天，為何有此一問？我想暫且歸於辯證思維。但基於此思維模式下回答這個問題並不容易——完整地回答這個問題，需要從程式設計正規化的理論基礎、發展歷程及應用場景來闡述。這裡就拋開那些長篇大論，就這個問題本身而言，存在即合理，我們不能簡單地去歸類“它”是錯的還是對的。為了避免話題引起類似OOP VS Functional P或OOP VS Procedural P的純粹的對立性爭論，例如：喜歡面向物件程式設計的開發人員認為，在建立程式方面，它比函式程式設計方法更好，相反，支援函式程式設計的開發人員認為，他們的方法更好。OOP的支持者認為，繼承和封裝的概念更易於管理和操作資料，而函數語言程式設計的支持者認為，資料和方法的分離以及使用該方法實現的高階抽象，為錯誤留下的空間非常小......這類爭論也將是無休止的；所以我試著從OOP的優缺點來看待它。

優點

作為一種能被多數開發語言所採用的程式設計正規化，必定有其巨大的優勢所在。

提高的軟體開發效率

OOP是模組化的，因為它在基於物件的程式開發中提供了職責分離。

OOP也是可擴充套件的，因為物件可以被擴充套件以包含新的屬性和行為。

物件還可以在跨應用程式中重用；面向物件程式語言提供了豐富的物件庫，在專案期間開發的程式碼也可以在未來的專案中重用。

由於這三個因素（模組化、可擴充套件性和可重用性），OOP提供了比傳統面向過程的程式設計正規化有更高的軟體開發效率。

提高軟體可維護性

基於上述原因，面向物件軟體也更容易維護。

由於設計是模組化的，系統的一部分可以在出現問題時進行更新，而不需要進行大規模的更改。

更低的開發成本

軟體的重用也降低了開發成本。通常，更多的工作被投入到面向物件的分析和設計中，這降低了開發的總體成本。

更高質量的軟體

更快的軟體開發和更低的開發成本允許在軟體驗證中使用更多的時間和資源。

儘管質量取決於團隊的經驗，但面向物件程式設計往往能夠產生更高質量的軟體。

缺點陡峭的學習曲線

對一些人來說，面向物件程式設計所涉及的思維過程可能不是很自然，需要一些專案經驗來理解。

一些關鍵的程式設計技術，例如物件設計原則和設計模式，需要有足夠的OOD經驗才能真正領會其意圖。

更大的體積

面向物件的程式通常比面向過程程式包含更多的程式碼行。

效能較低

面向物件程式通常比面向過程的程式慢，因為它們通常需要更多的指令來執行。

並不是所有型別的問題都適合

有些問題適合函數語言程式設計正規化、邏輯程式設計正規化或面向過程的程式設計正規化，在這些情況下應用面向物件程式設計不能開發出高效的程式。

總結

沒有哪種方法是放之四海而皆準的，脫開實際應用場景單論哪種方法也不可取。畢竟所有的努力是為解決問題，吸取各種方法所長，靈活運用方是正道。