《設計模式筆記》之01七大原則

單一職責原則

---

• 核心

  一個類只負責一項職責

• 優勢

  1. 下降類的複雜度
  2. 提升類的可讀性和可維護性
  3. 下降變動引發的風險
  4. 若是邏輯比較簡單，能夠在方法上遵照單一職責，下降代碼量

• 實例

  1. 交通工具

     分爲輪船，飛機、汽車。每一個類實現一個職責

  2. DAO類

     一個DAO負責一個表的增刪改查。

• 代碼

  代碼部分參考了尚硅谷韓順平老師的內容。

  /**
   * @program:design_pattern
   * @descript:公路
   * @author: luyongjian746
   * @create: 2020-02-11
   */
  public class Road {
  
      public void run(String vehicle) {
          System.out.println(vehicle + "在公路上跑");
      }
  }

  /**
     * @program:design_pattern
     * @descript:天空
     * @author: luyongjian746
     * @create: 2020-02-11
     */
    public class Sky {
  
        public void run(String vehicle) {
            System.out.println(vehicle + "在空中飛");
        }
    }

  /**
   * @program:design_pattern
   * @descript:海
   * @author: luyongjian746
   * @create: 2020-02-11
   */
  public class Sea {
  
      public void run(String vehicle) {
          System.out.println(vehicle + "在海中航行");
      }
  }

  /**
   * @program:design_pattern
   * @descript:測試
   * @author: luyongjian746
   * @create: 2020-02-11
   */
  public class Test {
  
      public static void main(String[] args) {
          Road road = new Road();
          road.run("汽車");
  
          Sky sky = new Sky();
          sky.run("飛機");
  
          Sea sea = new Sea();
          sea.run("輪船");
      }
  }

  結果：

  汽車在公路上跑
  飛機在空中飛
  輪船在海中航行

接口隔離原則

---

• 核心

  客戶端不該該依賴於他不須要的接口。即一個類對另一個類的依賴，應該創建在最小的接口上。

  將大接口拆解成多個小的接口。

• 做用

  1. 將臃腫龐大的接口分解爲多個粒度小的接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。
  2. 接口隔離提升了系統的內聚性，減小了對外交互，下降了系統的耦合性。
  3. 若是接口的粒度大小定義合理，可以保證系統的穩定性；可是，若是定義太小，則會形成接口數量過多，使設計複雜化；若是定義太大，靈活性下降，沒法提供定製服務，給總體項目帶來沒法預料的風險。
  4. 使用多個專門的接口還可以體現對象的層次，由於能夠經過接口的繼承，實現對總接口的定義。
  5. 能減小項目工程中的代碼冗餘。過大的大接口裏面一般放置許多不用的方法，當實現這個接口的時候，被迫設計冗餘的代碼。

依賴倒置原則

---

• 核心

  高層模塊不該該依賴低層模塊，二者都應該依賴其抽象；抽象不該該依賴細節，細節應該依賴抽象。

  其核心思想是：要面向接口編程，不要面向實現編程。

• 做用

  1. 依賴倒置原則能夠下降類間的耦合性。

  2. 依賴倒置原則能夠提升系統的穩定性。

  3. 依賴倒置原則能夠減小並行開發引發的風險。

  4. 依賴倒置原則能夠提升代碼的可讀性和可維護性。

裏式替換原則

---

• 核心

  子類繼承父類時儘可能不要重寫父類的方法。

• 優勢

• 實例

• 代碼

開閉原則

---

• 核心

  對擴展開放，對修改關閉。用抽象構建框架，用實現擴展細節。

• 做用

  開閉原則是面向對象程序設計的終極目標，它使軟件實體擁有必定的適應性和靈活性的同時具有穩定性和延續性。具體來講，其做用以下。

  1. 對軟件測試的影響

  軟件遵照開閉原則的話，軟件測試時只須要對擴展的代碼進行測試就能夠了，由於原有的測試代碼仍然可以正常運行。

  2. 能夠提升代碼的可複用性

  粒度越小，被複用的可能性就越大；在面向對象的程序設計中，根據原子和抽象編程能夠提升代碼的可複用性。

  3. 能夠提升軟件的可維護性

  遵照開閉原則的軟件，其穩定性高和延續性強，從而易於擴展和維護。

迪米特法則

---

• 核心

  子類能夠擴展父類的功能，但不能改變父類原有的功能。

  若是不是直接朋友，在一個方法中出現了其餘類的局部變量，就違反了迪米特法則。

  直接朋友是指，某方法的參數，返回值所使用的類，則此類爲該方法所屬類的直接朋友。

• 做用

  1. 下降了類之間的耦合度，提升了模塊的相對獨立性。
  2. 因爲親合度下降，從而提升了類的可複用率和系統的擴展性。

合成複用原則

---

• 核心

  儘可能使用合成或複用代替繼承。

  合成：A類做爲成員變量或者參數的形式出如今B類

  複用：A類以new A()的方式出如今B類中

• 做用

  1. 它維持了類的封裝性。由於成分對象的內部細節是新對象看不見的，因此這種複用又稱爲「黑箱」複用。
  2. 新舊類之間的耦合度低。這種複用所需的依賴較少，新對象存取成分對象的惟一方法是經過成分對象的接口。
  3. 複用的靈活性高。這種複用能夠在運行時動態進行，新對象能夠動態地引用與成分對象類型相同的對象。