設計模式的六大原則

參考：

• 設計模式六大原則

1. 單一職責原則

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

優(yōu)點：

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

2. 里氏替換原則

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

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

實現(xiàn)方法：

子類可以實現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法；

允許子類拓展父類的方法

當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。

當子類的方法實現(xiàn)父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

3. 依賴倒置原則

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

比如手機（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類，然后各自實現(xiàn)，高層模塊只依賴于抽象的低層模塊。

實現(xiàn)方法：

低層模塊盡量都要有抽象類或接口，或者兩者都有。

變量的聲明類型盡量是抽象類或接口。

使用繼承時遵循里氏替換原則。

4. 接口隔離原則

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

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

接口隔離原則

5. 迪米特法則

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

高內(nèi)聚，低耦合

6. 開閉原則

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

總結(jié)

以上是生活随笔為你收集整理的【设计模式 00】设计模式的六大原则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。