翻譯 | The Principles of OOD 面向對象設計原則

時間 2019-12-12

原文原文鏈接

本文首發於vivo互聯網技術微信公衆號 java

https://mp.weixin.qq.com/s/Q_pziBUhKRywafKeY2T7YQc++

做者：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 重用發佈等價原則重用的顆粒就是釋放的顆粒。