The Principles of OOD 物件導向設計原則

本文首發於vivo網際網路技術微信公眾號 

https://mp.weixin.qq.com/s/Q_pziBUhKRywafKeY2T7YQ

作者：Robert C. Martin

翻譯：張碩

本文由來自美國業界大牛——Robert C. Martin（俗稱“Bob大叔） 釋出在 butunclebob.com 上，已獲得翻譯授權。

英文原文連結：

本篇概括性的介紹了OOD的設計原則，後續還有更多文章會詳細剖析、吃透物件導向業務設計的原則。

什麼是物件導向設計？它是怎麼一回事？使用它會有什麼利弊得失？似乎問出這些問題顯得有些愚蠢，特別是在一個幾乎每個開發者都會使用某種面嚮物件語言的時代中。

然而在我看來，這些問題即極為重要，因為我們中的大多數使用者並不知道答案，當然也不知道如何發揮面嚮物件語言的最大價值。

在我們這個行業發生的所有變革中，有兩場是非常成功的，以至於它們已經滲透到我們的思維中，以至於我們認為它們是理所當然的。那就是"結構化設計\程式設計"(也叫程式導向設計)與"物件導向設計\程式設計"。所有主流的現代程式語言都被這兩種程式設計正規化深刻影響。甚至是，我們很難摒棄這兩種程式設計正規化去寫任何一個程式。

我們的主流程式語言中沒有“GOTO”，因此似乎是遵守了著名的結構化程式設計"禁令"；我們大多數的主流程式語言是基於類並且不支援使用沒有寫入任何一個類中的變數、函式(方法)，因此他們似乎是遵守了物件導向設計中最明顯的特點。

用這些語言(主流結構化語言或面嚮物件語言)寫出的程式也許看上去是結構化的或物件導向的，但是外表也可以是虛假的。今天的程式設計師常常不知道這些語言產生的原因以及其中的基礎原則。在另一篇部落格中，我會討論結構化程式設計的設計原則，而在這篇文章中我想要聊聊物件導向設計原則。

在1995年3月，在comp.object上，我寫過一篇文章，這篇文章也成為我日後眾多OOD設計原則文章中的處女作。你們將會在我的PPP書籍中以及發表了我多篇文章的objectmentor網站上看到這些文章，當然也包括那個廣為人知的那篇摘要文章。（ 譯者注：PPP指——“Agile Software Development: Principles, Patterns, and Practice,中文即—敏捷軟體開發：原則、模式與實踐” ）

這些原則揭示了OOD依賴管理方面的內涵，而在概念化和建模方面並沒有深入涉及。然而這並不代表OO在對問題領域的概念化上很薄弱，也不代表OO在建模能力上很薄弱。我很確定在這兩方面上，很多從OO設計原則中獲得價值。需要注意的是，這些原則非常關注依賴關係管理。

（ 譯者注：此處指寬泛概念的依賴關係管理，如系統與系統之間的依賴，模組與模組之間的依賴，類方法直接的依賴 ）

依賴管理是一個大多數架構師需要面對的問題。每當我們在螢幕上看到一堆亂七八糟的遺留程式碼時，我們都在經歷依賴管理不善的結果。糟糕的依賴關係管理導致程式碼難以更改、脆弱和不可重用。實際上，在我的PPP書中談到了幾種不同的設計風格，都與依賴管理有關。另一方面，當依賴關係得到很好的管理時，程式碼仍然是靈活可擴充套件的、健壯的和可重用的。因此，依賴關係管理的思考，以及這些原則的使用，是軟體開發人員設計靈活性系統的基礎。

以下5個原則是階級設計原則：

SRP單一職責原則  指一個類\模組\包甚至系統 都應該有單一的原則。

OCP開閉原則  你應該能夠擴充套件類的行為，而不需要修改它。

如果軟體系統想要更容易被改變，其設計就必須允許新增程式碼來修改，而非修改原來程式碼。

LSP 里氏替換原則

簡答理解就是 如果想要可替換的元件來構建軟體系統，那麼這些元件就必須遵守共同一個約定，以便讓這些元件可以相互替換。

ISP 介面隔離原則

使細粒度介面特定於客戶端,主要告誡設計師應該在設計中避免不必要的依賴。

DIP 依賴倒置原則

依賴抽象，而非具體實現。此原則指出高層策略性程式碼不應該依賴實現的程式碼，相反，那些底層實現應該依賴於高層策略程式碼。（ 譯者注：這裡的“類”泛指：方法和資料的耦合分組 ）

接下來的六條原則是關於包（譯者注：指jar、war，而非package）的。在這個上下文中，包是二進位制的可交付檔案，比如：jar檔案，或者dll，而不是java包或c++名稱空間。前三個包原則是關於包內聚的，它們告訴我們在包中放入什麼：

REP 重用釋出等價原則  重用的顆粒就是釋放的顆粒。

CCP 共同封閉原則  一起更改的類被打包在一起。

CRP 共同重用原則  一起使用的類被打包在一起。

ADP 無環依賴原則  包的依賴關係圖必須沒有迴圈。

SDP 穩定依賴原則  依賴於穩定性的方向，特別是（變化更多的）具體的元素應該取決於是否要完全依賴於（更穩定的）抽象成分。

SAP 穩定抽象原則  抽象性隨穩定性而增加。