JAVA 設計模式遵循的六大基本準則

JAVA 設計模式遵循的六大基本準則

1、單一職責原則：（Single Responsibility Pinciple）

　　 一個類只負責一項職責。 當超過一項職責須要負責時，須要增長新的類來負責新的職責，而不是在類中個性代碼。

　　若是一個類承擔的職責太多，就是高度地職責耦合，很是不利於擴展功能。這是很是脆弱的設計。 容易發生修改一個地方而影響其餘地方的狀況。

       遵循單一職責原則的優勢：

1.        下降類的複雜度
2.        提升類的可讀性，提升系統的可維護性
3.        變動引發的風險下降

2、里氏代換原則：（Liskov Substitution Principle,簡稱LSP）子類能夠擴展父類的功能，但不能改變父類原有的功能

里氏代換原則(Liskov Substitution Principle, LSP)：全部引用基類（父類）的地方必須能透明地使用其子類的對象。

里氏代換原則告訴咱們，在一個軟件系統中，子類應該能夠替換任何基類可以出現的地方，而且通過替換之後，代碼還能正常工做。子類也可以在基類的基礎上增長新的行爲。

      例若有兩個類，一個類爲BaseClass，另外一個是SubClass類，而且SubClass類是BaseClass類的子類，那麼一個方法若是能夠接受一個BaseClass類型的基類對象base的話，如：method1(base)，那麼它必然能夠接受一個BaseClass類型的子類對象sub，method1(sub)可以正常運行。反過來的代換不成立，如一個方法method2接受BaseClass類型的子類對象sub爲參數：method2(sub)，那麼通常而言不能夠有method2(base)，除非是重載方法。

      里氏代換原則是實現開閉原則的重要方式之一，因爲使用基類對象的地方均可以使用子類對象，所以在程序中儘可能使用基類類型來對對象進行定義，而在運行時再肯定其子類類型，用子類對象來替換父類對象。

包含4層含義：

1.         子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.         子類中能夠增長本身特有的方法。
3.         當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
4.         當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

        不遵循里氏代換原則的後果是，寫代碼出錯的機率會大大增長。

 

3、依賴倒置原則（Dependence Inversion Principle,簡稱DIP）

　　定義：1.高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象； 2.抽象不該該依賴細節；細節應該依賴抽象。

　　問題由來：類A直接依賴類B，假如要將類A改成依賴類C，則必須經過修改類A的代碼來達成。這種場景下，類A通常是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操做；假如修改類A，會給程序帶來沒必要要的風險。

　　解決方案：將類A修改成依賴接口I，類B和類C各自實現接口I，類A經過接口I間接與類B或者類C發生聯繫，則會大大下降修改類A的概率。

       依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。

　　傳遞依賴的三種寫法： 

1.構造函數傳遞依賴對象 
2.Setter方法傳遞依賴對象 
3.接口聲明傳遞依賴對象 

深刻了解能夠看：輕鬆學，淺析依賴倒置（DIP）、控制反轉(IOC)和依賴注入(DI)

 4、接口隔離原則（Interface Segregation Principle,簡稱ISP）

• 核心思想：類間的依賴關係應該創建在最小的接口上
• 通俗來說：創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用。

　舉例

　   問題由來：類A經過接口I依賴類B，類C經過接口I依賴類D，若是接口I對於類A和類B來講不是最小接口，則類B和類D必須去實現他們不須要的方法。

　　舉例來講明接口隔離原則：

（圖1  未遵循接口隔離原則的設計）

         這個圖的意思是：類A依賴接口I中的方法一、方法二、方法3，類B是對類A依賴的實現。類C依賴接口I中的方法一、方法四、方法5，類D是對類C依賴的實現。對於類B和類D來講，雖然他們都存在着用不到的方法（也就是圖中紅色字體標記的方法），但因爲實現了接口I，因此也必需要實現這些用不到的方法。

　　解決方案：將臃腫的接口I拆分爲獨立的幾個接口，類A和類C分別與他們須要的接口創建依賴關係。也就是採用接口隔離原則。

 　　能夠看到，若是接口過於臃腫，只要接口中出現的方法，無論對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。若是將這個設計修改成符合接口隔離原則，就必須對接口I進行拆分。在這裏咱們將原有的接口I拆分爲三個接口，拆分後的設計如圖2所示：

（圖2  遵循接口隔離原則的設計）

 

• 需注意：
• 接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計靈活性，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度
• 提升內聚，低耦合=減小對外交互。每一個模塊儘量獨立完成本身的功能，不依賴於模塊外部的代碼。內聚和耦合是密切相關的，同其餘模塊存在高耦合的模塊意味着低內聚，而高內聚的模塊意味着該模塊同其餘模塊之間是低耦合。在進行軟件設計時，應力爭作到高內聚，低耦合。
• 爲依賴接口的類定製服務。只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。

5、迪米特法則（Law of Demeter,簡稱LoD）

　　迪米特法則有不少種說法，好比：一個類應該應該對其餘類儘量瞭解得最少；類只與直接的朋友通訊等等。可是其最終目的只有一個，就是讓類間解耦。

　　定義

• 　　　　迪米特法則：Law Of Demeter，LoD。
• 　　　　也被稱爲最少知識原則，Least Knowledge Principle，LKP。

　　就是說一個對象應該對其餘對象保持最少的瞭解。正如最少知識原則這個定義同樣，一個類應該對其耦合的其餘類或所調用的類知道得最少。所耦合的類內部不管如何複雜，怎麼實現的我都不須要知道，我只調用你public出來的這些方法，其餘都不用知道。

　　參考文檔-迪米特法則

 

6、開放封閉原則（Open Close Principle,簡稱OCP）

　　所謂開放封閉原則就是軟件實體應該對擴展開放，而對修改封閉（不須要修改接口，就能實現新的需求）。開放封閉原則是全部面向對象原則的核心。軟件設計自己所追求的目標就是封裝變化，下降耦合，而開放封閉原則正是對這一目標的最直接體現。

　　開放封閉原則主要體如今兩個方面：

•    對擴展開放，意味着有新的需求或變化時，能夠對現有代碼進行擴展（根據接口添加新的實現類），以適應新的狀況。
•    對修改封閉，意味着類一旦設計完成，就能夠獨立其工做，而不要對類盡任何修改也能知足新的需求。

　　爲何要用到開放封閉原則呢？

　　　　軟件需求老是變化的，世界上沒有一個軟件的是不變的，所以對軟件設計人員來講，必須在不須要對原有系統進行修改的狀況下，實現靈活的系統擴展。

　　如何作到對擴展開放，對修改封閉呢？

       實現開放封閉的核心思想就是對抽象編程，而不對具體編程，由於抽象相對穩定。讓類依賴於固定的抽象，因此對(抽象類)修改就是封閉的；而經過面向對象的繼承和多態機制，能夠實現對抽象體的繼承，經過覆蓋其方法來改變固有行爲，實現新的擴展方法，因此對於擴展就是開放的（即對接口添加新的實現類來知足新的需求）。

       對於違反這一原則的類，必須經過重構來進行改善。經常使用於實現的設計模式主要有Template Method模式和Strategy 模式。而封裝變化，是實現這一原則的重要手段，將常常變化的狀態封裝爲一個類。

代碼參考例子：以銀行業務員爲例

總結：

1. 單一職責原則告訴咱們實現類要職責單一；
2. 里氏替換原則告訴咱們不要破壞繼承體系；
3. 依賴倒置原則告訴咱們要面向接口編程；
4. 接口隔離原則告訴咱們在設計接口的時候要精簡單一；
5. 迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。