此篇只是對六大原則做了下總結，具體可看??鏈接：
1. 設計模式之單一職責原則
2. 設計模式之里式替換原則
3. 設計模式之依賴倒置原則
4. 設計模式之接口隔離原則
5. 設計模式之迪米特法則
6. 設計模式之開閉原則

1. 設計模式之單一職責原則

一個類只負責一項職責，不要存在 1 個以上導致類發生變更的原因。

• 優點：
  a. 降低類的復雜度，一個類只負責一項職責，邏輯簡單清晰；
  b. 類的可讀性，系統的可維護性更高；
  c. 因需求變更引起的風險更低，降低對其它功能的影響。

• 總結：
  只有邏輯足夠簡單，才可以在代碼級別上違反單一職責原則；
  只有類中方法數量足夠少，才可以在方法級別上違反單一職責原則；
  模塊化的程序設計以及在員工工作安排上面，都適用單一職責原則。

2. 設計模式之里式替換原則

子類可以擴展父類的功能，不能改變父類原有的功能，子類可以替換父類，方法或者行為也沒有改變

• 注意：
  a. 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法；
  b. 子類中可以增加自己特有的方法；
  c. 當子類的方法重載父類的方法時，方法的前置條件（形參）要比父類方法更寬松；
  d. 當子類的方法實現父類的抽象方法時，方法的后置條件（返回值）要比父類更嚴格。

3. 設計模式之依賴倒置原則

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

• 理解：
  a. 相對于細節的多變性，抽象的東西要穩定的多，以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。這里，抽象指的是接口或者抽象類，細節就是具體的實現類，使用抽象類或者接口的目的是，制定好規范和契約，不去涉及任何具體的操作，把展現細節的任務交給實現類來完成；

  b. 依賴倒置原則的核心思想是面向接口編程，達到解耦的過程。

• 注意：
  a. 底層模塊盡量都要有抽象類或者接口；
  b. 變量的聲明類型盡量是抽象類或接口；
  c. 使用繼承時遵循里式替換原則。

4. 設計模式之接口隔離原則

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

• 理解：
  a. 建立單一接口，盡量細化接口，接口中的方法盡量少；
  b. 為單個類建立專用的接口，不要包含太多；
  c. 依賴幾個專用的接口要比依賴一個綜合的接口更靈活，提高系統的靈活性和可維護性。

• 注意：
  a. 接口盡量小，但是要有限度，過小則導致接口數量過多，設計復雜化；
  b. 為依賴接口的類定制服務，只暴露給調用類需要的方法，建立最小的依賴關系；
  c. 提高內聚，減少對外交互，用最少的方法去完成最多的事情。

• 和單一職責原則的對比：
  a. 單一職責原則注重的是職責，而接口隔離原則注重對接口依賴的隔離；
  b. 單一職責原則主要是約束類，其次才是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口，針對抽象和程序整體框架的構建。

5. 設計模式之迪米特法則

迪米特法則在于降低類之間的耦合，每個類盡量減少對其他類的依賴，盡量減少對外暴露的方法，使得功能模塊獨立，低耦合

• 理解：
  a. 只直接的朋友交流（成員變量、方法的輸入輸出參數中的類）；
  b. 減少對朋友的理解（減少一個類對外暴露的方法）。

• 注意：
  a. 雖然可以避免和非直接的類通信，但是要通信，必然會通過一個”中介“來發生聯系，過分的使用迪米特原則，會產生大量的中介和傳遞類，導致系統復雜度變高。

6. 設計模式之開閉原則

軟件中的對象（類、模塊、函數等）應該對于擴展是開放的，對于修改是封閉的

• 理解：
  a. 當需求發生變化時，盡量擴展實體的行為來變化，而不是通過修改已有的代碼來實現變化；
  b. 低層模塊的變化，必然有高層模塊進行耦合，它并不意味著不做任何修改；
  c. 這個原則比較虛，可以通過具體的設計模式的設計思維去加深理解。

7. 總結

• 單一職責原則告訴我們實現類要職責單一；
• 里氏替換原則告訴我們不要破壞繼承體系；
• 依賴倒置原則告訴我們要面向接口編程；
• 接口隔離原則告訴我們在設計接口的時候要精簡單一；
• 迪米特法則告訴我們要降低耦合；
• 而開閉原則是總綱，他告訴我們要對擴展開放，對修改關閉。