設計模式的六大原則

參考：

• 設計模式六大原則

1. 單一職責原則

一個類只負責一個明確的功能

優點：

• 降低類的復雜度，提高代碼可讀性和可維護性
• 降低變更時對其他功能的影響

2. 里氏替換原則

**原則一：**若 o1 是 C1 的一個實例化對象， o2 是 C2 的一個實例化對象，如果在使用 C1 的程序中將o1 替換為 o2 而程序行為沒有發生變化，那么 C2 應該是 C1 的子類。

**原則二：**所有用到基類對象的地方，如果把基類對象替換成子類對象，程序行為不應該發生變化。

實現方法：

1. 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法；
2. 允許子類拓展父類的方法
3. 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
4. 當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

3. 依賴倒置原則

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

比如手機（Phone）依賴CPU，那么 Phone 就是一個高層模塊， CPU 就是一的低層模塊，Phone 顯然不應該依賴一個具體的低層模塊（如 Qualcomm865）：

public class Phone {private Qualcomm cpu;Phone(){this.cpu = new Qualcomm();}public void printConfig(){System.out.println("cpu is" + this.cpu);}
}

不管是高通還是麒麟，都應該抽象為一個CPU類，然后各自實現，高層模塊只依賴于抽象的低層模塊。

實現方法：

1. 低層模塊盡量都要有抽象類或接口，或者兩者都有。
2. 變量的聲明類型盡量是抽象類或接口。
3. 使用繼承時遵循里氏替換原則。

4. 接口隔離原則

客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。

使用多個隔離的接口，比使用單個接口要好.

接口隔離原則

5. 迪米特法則

一個對象應該對其他對象保持最少的了解。

高內聚，低耦合

6. 開閉原則

對拓展開放，對修改封閉：當系統變化時，盡量通過拓展來實現變化，而不是去修改原有代碼；