The Principles of OOD
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Robert C. Martin
本文翻譯，已獲得原作者Robert C. Martin授權，未經允許請勿轉載。
什麼是面向對象設計？它是怎麼一回事？使用它會有什麼利弊得失？
似乎問出這些問題顯得有些愚蠢，特別是在一個幾乎每個開發者都會使用某種面嚮對象語言的時代中。
然而在我看來，這些問題即極爲重要，因爲我們中的大多數使用者並不知道答案，當然也不知道如何發揮面嚮對象語言的最大價值。
在我們這個行業發生的所有變革中，有兩場是非常成功的，以至於它們已經滲透到我們的思維中，以至於我們認爲它們是理所當然的。
那就是"結構化設計\編程"(也叫面向過程設計)與"面向對象設計\編程"。
所有主流的現代編程語言都被這兩種編程範式深刻影響。甚至是，我們很難摒棄這兩種編程範式去寫任何一個程序。
我們的主流編程語言中沒有“GOTO”，因此似乎是遵守了著名的結構化編程"禁令"；
我們大多數的主流編程語言是基於類並且不支持使用沒有寫入任何一個類中的變量、函數(方法)，因此他們似乎是遵守了面向對象設計中最明顯的特點。
用這些語言(主流結構化語言或面嚮對象語言)寫出的程序也許看上去是結構化的或面向對象的，但是外表也可以是虛假的。
今天的程序員常常不知道這些語言產生的原因以及其中的基礎原則。
在另一篇博客中，我會討論結構化編程的設計原則，而在這篇文章中我想要聊聊面向對象設計原則。
在1995年3月，在comp.object課程中，我寫過一篇文章，這篇文章日後也成爲我日後衆多OOD設計原則文章中的處女作。
你們將會在我的PPP書籍中以及發表了我多篇文章的objectmentor網站上看到這些文章，當然也包括那個廣爲人知的那篇摘要文章。
[PPP指：Agile Software Development: Principles, Patterns, and Practices(敏捷軟件開發：原則、模式與實踐)。]
這些原則揭示了OOD依賴管理方面的內涵，而在概念化和建模方面並沒有深入涉及。
然而這並不代表OO在對問題領域的概念化抽象上很薄弱，也不代表OO在建模能力上很薄弱。
我很確定在這兩方面上，很多從OO設計原則中獲得價值。需要注意的是，這些原則非常關注依賴關係管理。
[此處指寬泛概念的依賴關係管理，如系統與系統之間的依賴，模塊與模塊之間的依賴，類方法直接的依賴]
依賴管理是一個大多數架構師需要面對的問題。每當我們在屏幕上看到一堆亂七八糟的遺留代碼時，我們都在經歷依賴管理不善的結果。
糟糕的依賴關係管理導致代碼難以更改、脆弱和不可重用。
實際上，在我的PPP書中談到了幾種不同的設計風格，都與依賴管理有關。
另一方面，當依賴關係得到很好的管理時，代碼仍然是靈活可擴展的、健壯的和可重用的。
因此，依賴關係管理的思考，以及這些原則的使用，是軟件開發人員設計靈活性系統的基礎。
以下5個原則是類的設計原則：
SRP單一職責原則
指一個類\模塊\包甚至系統 都應該有單一的原則
OCP開閉原則
你應該能夠擴展類的行爲，而不需要修改它。如果軟件系統想要更容易被改變，其設計就必須允許新增代碼來修改，而非修改原來代碼。
LSP 里氏替換原則
簡答理解就是 如果想要可替換的組件來構建軟件系統，那麼這些組件就必須遵守共同一個約定，以便讓這些組件可以相互替換。
ISP 接口隔離原則
使細粒度接口特定於客戶端,主要告誡設計師應該在設計中避免不必要的依賴。
DIP 依賴倒置原則
依賴抽象，而非具體實現。
指出高層策略性代碼不應該依賴實現的代碼，相反，那些底層實現應該依賴於高層策略代碼。
[這裏類泛指:方法和數據的耦合分組]
接下來的六條原則是關於包的。
在這個上下文中，包是二進制的可交付文件，比如.jar文件，或者dll，而不是java包或c++命名空間。
前三個包原則是關於包內聚的，它們告訴我們在包中放入什麼:
REP 重用發佈等價原則 重用的顆粒就是釋放的顆粒.
CCP 共同封閉原則 一起更改的類被打包在一起。
CRP 共同重用原則 一起使用的類被打包在一起。
ADP 無環依賴原則 包的依賴關係圖必須沒有循環。
SDP 穩定依賴原則
依賴於穩定性的方向，特別是 ，（變化更多的）具體的元素應該取決於是否要完全依賴於（更穩定的）抽象成分
SAP 穩定抽象原則 抽象性隨穩定性而增加。
文章至此翻譯結束，後續文章會詳細剖析、吃透SOLID原則。