前面的文章講述了設計模式的3大類型，下面講述一下設計模式遵循的6大原則
單一職責原則
- 定義
有且只有一個原因引起類的變更
- 優勢
類的複雜性降低，任何職責實現都有明確清晰的定義; 可讀性提高; 可維護性提高; 變更引起的風險降低。
- 最佳實踐
接口，在設計的時候，一定要做到單一。但是，對於接口的實現類需要根據具體業務多方面考慮。 單一職責原則不僅僅適用於接口和類，同時也適用於方法——一個方法儘可能只做一件事情。
- 總結
接口一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。
裡式替換原則
- 定義
所有應用基類的地方必須能透明地使用其子類的對象(只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或者異常。使用者可能根本不需要知道使用的是父類還是子類)。
- 最佳實踐
在類中調用其他類時，務必使用父類或者接口。如果不能使用父類或者接口，說明類的設計已經違背了LSP原則。如果子類不能完整地實現父類的方法，或者父類的某些方法在子類中已經發生了“畸變”（Override），則建議斷開父子的繼承關係，而是通過依賴、聚集或者組合等關係代替繼承。覆蓋或實現父類的方法時，輸入參數可以被放大。即：子類中方法的前置條件(輸入參數)必須與超類中被覆寫的方法的前置條件相同或者更寬鬆。覆寫或實現父類的方法時，輸出結果可以被縮小。
- 總結
採用里氏替換原則的目的是增強程序的健壯性，版本升級的時候可以保持非常好的兼容性。即使增加了子類，原有的子類還可以繼續運行。
依賴倒置原則
- 定義
高層模塊不應該依賴低層模塊，兩者都應該依賴抽象。抽象不應該依賴細節。細節應該依賴抽象。
- 最佳實踐
依賴倒置原則的本質是通過抽象(接口或者抽象類)使各個類或模塊的實現彼此獨立，互不影響，從而實現模塊間的松耦合。 在具體項目中實現依賴倒置原則，需要遵循以下幾個規則：
每個類儘量都有接口或者抽象類，或者接口和抽象類兩者都具備。這是依賴倒置原則的基本要求，抽象和接口類屬於抽象的，有了抽象才能實現依賴倒置。
變量的表面類型儘量使接口或者抽象類。特例：如果需要使用類的clone方法，就必須使用實現類（JDK的規範）。任何類都不應該從具體類派生。
儘量不要覆寫積累的方法。如果基類是一個抽象類，並且某個方法已經實現了，那麼子類儘量不要覆寫。類間依賴的是抽象，如果覆寫了抽象的某個方法，對依賴的穩定性會產生一定影響。 結合里氏替換原則使用。
接口負責定義public屬性和方法，並且聲明與其它對象的依賴關係；抽象類負責公共部分的實現；實現類準確實現業務邏輯，同時在適當的時候對父類進行細化。
依賴倒置原則是實現開閉原則的重要途徑，也是六大原則中最難以實現的原則。如果依賴倒置原則沒有實現，就難以實現開閉原則（對擴展開放，對修改關閉）。
接口隔離原則
- 定義
定義一： 客戶端不應該依賴它不需要的接口。
定義二： 類間的依賴關係應該建立在最小的接口上。也就是說，應該建立單一接口，不要建立臃腫龐大的接口。接口儘量細化，同時接口中的方法儘量少。要注意與單一職責原則的區分，兩者角度不同。單一職責原則要求類和接口職責單一，注重的是職責，是業務邏輯上的劃分；接口隔離原則要求接口的方法儘量少
- 最佳實踐
接口隔離原則是對接口和類的定義，接口和類儘量使用原子接口或原子類來組裝。這個“原子”的劃分，可以通過以下幾個規則來衡量：一個接口只負責一個子模塊或業務邏輯。通過業務邏輯壓縮接口中的public方法。已經被汙染了的接口，儘量去修改。若變更風險較大，則採用適配器模式進行轉化處理。瞭解應用場景，不要盲從。場景不同，接口拆分的標準就不同。根據應用場景和自己的經驗、常識，合理確定接口粒度大小。
迪米特原則
- 定義
一個對象應該對其他對象有最少的瞭解。因此又稱為最少知識原則(Least Knowledge Principle, LKP)。在迪米特原則中，一個類只和朋友類交流。朋友類：出現在成員變量、方法的輸入輸出參數中的類，稱為成員朋友類，而出現在方法內部的類不屬於朋友類。如果一個方法放在本類中，既不增加類間關係，也不對本類產生負面影響，就放在本類中。迪米特法則要求類儘量不要對外公佈太多的public方法和非靜態的public變量，儘量內斂，多使用private、package-private(default)、protected等訪問權限。
- 最佳實踐
迪米特原則的核心理念就是：類間解耦，弱耦合，從而提高類的複用率。結果是：產生了大量中轉或者跳轉類，導致系統複雜性提高，可維護性降低。使用迪米特原則，要反覆權衡，既做到結構清晰，又做到高內聚低耦合。
開閉原則
- 定義
一個軟件實體（類、模塊和防暑等）應該對擴展開放，對修改關閉。也就是說，一個軟件實體通過擴展來實現變化，而不是通過修改原來的代碼來實現變化。開閉原則是對軟件實體的未來事件而制定的對現行開發設計進行約束的一個原則。
軟件實體：
1 項目或軟件產品中按照一定的邏輯規則劃分的模塊
2 抽象或類
3 方法
- 最佳實踐
1 抽象約束
要實現對擴展開放，首要的前提條件是抽象約束。接口或抽象類可以約束一組可能變化的行為，並且能夠實現對擴展開放。抽象約束包含3層含義：
（1）約束擴展邊界
通過接口或抽象類約束擴展，對擴展進行邊界限定，不允許出現在接口或抽象類中不存在的public方法。
（2）約束參數類型 應用參數對象儘量使用接口或者抽象類，而不是實現類。
（3）抽象層儘量保持穩定
抽象層一旦確定，就不再允許修改。
2 元數據(metadata)控制模塊行為
元數據：用來描述環境和數據的數據，也就是配置參數。配置參數可以來自配置文件，也可以來自數據庫。
使用元數據來控制程序的行為，可以減少重複開發。
3 制定項目章程（約定優於配置）
團隊中應該有所有成員都必須遵守的開發約定。約定可以提高開發效率和溝通效率。
4 封裝變化
封裝變化有兩層含義：
將相同的變化封裝到一個接口或抽象類中；
將不同的變化封裝到不同的接口或抽象類中。
參考： 設計模式6大原則@簡書.Jerry_1116
