兩大設計策略

1. 從背景設計：

• 在設計各部分所呈現的細節之前先創建總體概念
• 共性和可變性分析

2. 類中封裝變化（適當）：

• 適應未來的變化
• 只實現哪些需要的特性，避免“分析癱瘓”

---

六大設計原則

• 單一職責原則——SRP

• 開閉原則——OCP

• 里式替換原則——LSP

• 依賴倒置原則——DIP

• 接口隔離原則——ISP

• 迪米特原則——LOD

---

1. 單一職責原則（The Single Responsibility Principle? ? ? SPR）

一個類應該應該有專用的職責，而不是“全家桶”，“萬金油”。

好處：降低復雜度，提高類的可讀性，和系統的維護性

---

2. 開閉原則（open-closed principle? ? OCP）

模塊，方法和類應該對擴展開放（OPEN），對修改封閉(CLOSE)。即：軟件設計不對其修改就能擴展功能，用抽象去構建框架，用實現擴展細節，這樣當發生修改的時候，我們就直接用抽象了派生一個具體類去實現修改。

本質：將軟件設計成為新功能能夠作為單獨的模塊加入系統，降低了集成成本。

---

3.里氏代換原則（The Liskov Substitution Principle? ? ?LSP）

子類型必須能夠替換掉它們的父類型，子類可以去擴展父類的功能，但是不能改變父類原有的功能，建立抽象，通過抽象去建立規范，然后用實現去擴展細節。 和COP是相互依存的。

• 子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法。

• 子類可以增加自己獨有的方法。

• 當子類的方法重載父類的方法時候，方法的形參要比父類的方法的輸入參數更加寬松。

• 當子類的方法實現父類的抽象方法時，方法的返回值要比父類更嚴格。

---

4. 依賴倒置原則（dependency inversion principle? ? DIP）

高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象，抽象不應該依賴細節， 細節應該依賴抽象。

模塊間的依賴是通過抽象來發生的，實現類之間不發生直接的依賴關系，其依賴關系是通過接口是來實現的。這就是俗稱的面向接口編程。

好處：具有很高的擴展性，降低了代碼之間的耦合度，提高了系統的穩定性。

---

5. 接口隔離原則（Interface Segregation Principle? ? ? ??ISP）

客戶端不應該依賴他不需要的接口，建立單一接口，只建立需要的，剔除多余的，多余的成為另外單一新接口。

---

6. 迪米特法則（Law of Demeter? ? ?LOD）：最少知識原則

一個對象應該對其他對象保持最小的了解。不要直接關系的類不要出現在類的內部。

好處：低耦合，高內聚。

---

其他思考

• 小心過分依賴模式
• 模式都是發現而非發明
• 概念層次的模式和模型都是真理的抽象
• 適合某個問題的模式就在問題之中，而不是強加在問題之上。
• 模式實現的具體方式由問題本質，約束條件和需求決定。
• 使用模式警惕常見誤區：浮于表面，偏見，錯選，誤判，削足適履。

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。