Java程序員應當知道的10個面向對象設計原則

Java程序員應當知道的10個面向對象設計原則
面向對象設計原則是OOPS編程的核心， 但我見過的大多數Java程序員熱心於像Singleton (單例) 、 Decorator(裝飾器)、Observer(觀察者) 等設計模式，而沒有把足夠多的注意力放在學習面向對象的分析和設計上面。學習面向對象編程像「抽象」、「封裝」、「多態」、「繼承」 等基礎知識是重要的，但同時爲了建立簡潔、模塊化的設計，瞭解這些設計原則也同等重要。我常常看到不一樣經驗水平的java程序員，他們有的不知道這些OOPS 和SOLID設計原則，有的只是不知道一個特定的設計原則會帶來怎樣的益處，甚至不知道在編碼中如何使用這些設計原則。

(設計原則)底線是永遠追求高內聚、低耦合的編碼或設計。 Apache 和 Sun的開源代碼是學習Java和OOPS設計原則的良好範例。它們向咱們展現了，設計原則在Java編程中是如何使用的。Java JDK 使用了一些設計原則：BorderFactory類中的工廠模式、Runtime類中的單例模式、java.io 類中的裝飾器模式。
雖然學習設計模式(原則)最好的方法是現實中的例子和理解違反設計原則帶來的不便，本文的宗旨是向那些沒有接觸過或正處於學習階段的Java程序員介紹面向對象設計原則。我我的認爲OOPS 和SOLID設計原則須要有文章清楚的介紹它們，在此我必定盡力作到這點，但如今請您準備瀏覽如下設計模式(原則) :)

DRY – Don’t repeat yourself

咱們第一個面向對象設計原則是：DRY ，從名稱能夠看出DRY(don’t repeat yourself)意思是不寫重複代碼，而是抽象成可複用的代碼塊。若是您有兩處以上相同的代碼塊，請考慮把它們抽象成一個單獨的方法；或者您屢次使用了硬編碼的值，請把它們設置成公共常量。這種面向對象設計原則的優勢是易於維護。重要的是不要濫用此原則，重複不是針對代碼而是針對功能來講。它的意思是，若是您使用通用代碼來驗證OrderID和SSN，這並不意味着它們是相同的或者他們從此將保持不變。經過把通用代碼用於實現兩種不一樣的功能，或者您把這兩種不一樣的功能密切地聯繫在一塊兒；當您的OrderID格式改變時，您的SSN驗證代碼將會中斷。因此要小心這種耦合，並且不要把彼此之間沒有任何關係卻相似的代碼組合在一塊兒。

封裝常常修改的代碼 Encapsulate What Changes

在軟件領域永遠不變的是「變化」，因此把您認爲或懷疑未來要被修改的代碼封裝起來。這種面向對象設計模式的優勢是：易於測試和維護恰當封裝的代碼。若是您在用Java編程，那麼請遵照如下原則：變量和方法的訪問權限默認設置爲私有，而且逐步放開它們的訪問權限，例如從「private」到「protected 」、「not public」。Java中的一些設計模式使用了封裝，工廠設計模式就是一個例子，它封裝了建立對象的代碼並且提供瞭如下靈活性：後續生成新對象不影響現有的代碼。

打開/關閉設計原則 OpenClosed Design Principle

類、方法/函數應當是對擴展(新功能)開放，對修改閉合。這是另一個優雅的SOLID 設計原則，以防止有人修改經過測試的代碼。理想狀況下假如您添加了新功能，那麼您的代碼要通過測試，這就是打開/關閉設計原則的目標。順便說一句，SOLID中的字母「O」指的是打開/關閉設計原則。

單一職責原則 Single Responsibility Principle(SRP)

單一職責原則是另一個SOLID設計原則，SOLID中的字母「S」指的就是它。按照SRP，一個類修改的緣由應當有且只有一個，或者一個類應當老是實現單一功能。若是您在Java中的一個類實現了多個功能，那麼這些功能之間便產生了耦合關係；若是您修改其中的一個功能，您有可能就打破了這種耦合關係，那麼就要進行另外一輪測試以免產生新的問題。

依賴注入/反轉原則 Dependency Injection or Inversion principle

不要問框架的依賴注入功能將會給你帶來什麼益處，依賴注入功能在spring框架裏已經很好的獲得了實現，這一設計原則的優雅之處在於：DI框架注入的任何一個類都易於用模擬對象進行測試，而且更易於維護，由於建立對象的代碼在框架裏是集中的並且和客戶端代碼是隔離的。有多種方法能夠實現依賴注入，例如使用字節碼工具，其中一些AOP(面向切面編程)框架如切入點表達式或者spring裏使用的代理。想對這種SOLID設計原則瞭解更多，請看IOC 和 DI設計模式中的例子。 SOLID中的字母「D」指的就是這種設計原則。

優先使用組合而非繼承 Favor Composition over Inheritance

若是能夠的話，要優先使用組合而非繼承。大家中的一些人可能爲此爭論，但我發現組合比繼承更有靈活性。組合容許在運行時經過設置屬性修改一個類的行爲，經過使用多態即以接口的形式實現類之間的組合關係，而且爲修改組合關係提供了靈活性。甚至 Effective Java也建議優先使用組合而非繼承。

里氏替換原則 Liskov Substitution Principle LSP

根據里氏替換原則，父類出現的地方能夠用子類來替換，例如父類的方法或函數被子類對象替換應該沒有任何問題。LSP和單一職責原則、接口隔離原則密切相關。若是一個父類的功能比其子類還要多，那麼它可能不支持這一功能，並且也違反了LSP設計原則。爲了遵循 LSP SOLID設計原則，派生類或子類(相對父類比較)必須加強功能，而非減小。SOLID中的字母「L」指的就是 LSP設計原則。

接口隔離原則

接口隔離原則指，若是不須要一個接口的功能，那麼就不要實現此接口。這大多在如下狀況發生：一個接口包含多種功能，而實現類只須要其中一種功能。接口設計是一種棘手的工做，由於一旦發佈了接口，您就不能修改它不然會影響實現該接口的類。在Java中這種設計原則的另外一個好處是：接口有一個特色，任何類使用它以前都要實現該接口全部的方法，因此使用功能單一的接口意味着實現更少的方法。

編程以接口(而非實現對象)爲中心

編程老是以接口(而非實現對象)爲中心，這會使代碼的結構靈活，並且任何一個新的接口實現對象都能兼容現有代碼結構。因此在Java中，變量、方法返回值、方法參數的數據類型請使用接口。這是許多Java程序員的建議， Effective Java 以及 head first design pattern 等書也這樣建議。

代理原則

不要指望一個類完成全部的功能，能夠適當地把一些功能交給代理類實現。代理原則的典範是：Java 中的equals() 和 hashCode() 方法。爲了比較兩個對象的內容是否相同，咱們讓用於比較的類自己完成對比工做而非它們的調用方。這種設計原則的好處是：沒有重複編碼並且很容易修改類的行爲。
喜歡這樣文章的能夠關注我，我會持續更新，大家的關注是我更新的動力！須要更多java學習資料的也能夠私信我！
祝關注個人人都：身體健康，財源廣進，福如東海,壽比南山，早生貴子，從不掉髮!