本篇概括性的介紹了OOD的設計原則，後續還有更多文章會詳細剖析、吃透面向對象業務設計的原則。 ...
本文首發於vivo互聯網技術微信公眾號
https://mp.weixin.qq.com/s/Q_pziBUhKRywafKeY2T7YQ
作者：Robert C. Martin
翻譯：張碩
本文由來自美國業界大牛——Robert C. Martin（俗稱“Bob大叔） 發佈在 butunclebob.com 上，已獲得翻譯授權。
英文原文鏈接：http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
本篇概括性的介紹了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 穩定抽象原則 抽象性隨穩定性而增加。
更多內容敬請關註 vivo 互聯網技術微信公眾號
註：轉載文章請先與微信號：labs2020 聯繫。
