1、單一職責原則

定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。

遵循單一職責原的優點有：

• 可以降低類的復雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
• 提高類的可讀性，提高系統的可維護性；
• 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

2、裏式替代原則

定義：所有引用基類的地方必須能透明地使用其子類的對象。即：子類可以擴展父類的功能，但不能改變父類原有的功能。

裏氏替換原則包含以下4層含義：

• 子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法。
• 子類中可以增加自己特有的方法。
• 當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

3、依賴倒置原則

三層含義：

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

精簡的定義： 面向接口編程。

最佳實踐：
1.每個類盡量都有接口或抽象類，或者抽象類和接口兩者都具備。
2.變量的表面類型盡量是接口或抽象類。
3.任何類都不應該從具體類派生。
4.盡量不要覆寫基類的方法。
5.結合裏氏替換原則使用。

4、接口隔離原則

概括：建立單一接口，不要建立臃腫龐大的接口。

通俗來講：接口盡量細化，同時接口中的方法盡量少。

保證接口的純結性：
1.接口要盡量小。
2.接口要高內聚。
3.定制服務。
4.接口的設計是有限度的。

最佳實踐：
1.一個接口只服務於一個子模塊或業務邏輯。
2.通過業務邏輯壓縮接口中的public方法，接口時常去回顧，盡量讓接口達到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。
3.已經被汙染了的接口，盡量去修改，若變更的風險較大，則采用適配器模式進行轉化處理。
4.了解環境，拒絕盲從。每個項目或產品都有特定的環境因素，不要盲從大師的設計，要根據業務邏輯進行最好的接口設計

5、迪米特法則（又稱最少知識原則）

定義：一個對象應該對其他對象保持最少的了解

通俗來講：一個類應該對自己需要耦合或調用的類知道得最少，你（被耦合或調用的類）的內部是如何復雜都和我沒有關系，那是你的事情，我就調用你提供的public方法，其他一概不關心。

6、開閉原則

定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉

當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。

面試寶典-設計模式六大原則