設計模式-六大原則
對於設計模式的六大原則，這裏打算用簡單幾句話來進行闡述。
單一職責原則
1 含義：簡單來講，就是類、接口和方法只負責一件事情，只有一個原因引起變化。一個接口一個職責，一個類一個職責。
2 好處：
-
類的複雜性降低
-
代碼可讀性提高
-
可維護性提高
-
變更引起的風險降低
3 難點：如何劃分職責？因爲職責和變化的原因是不可量化、不可度量的，所以那個接口或類負責哪個職責是很難劃分。這些需要根據具體項目來劃分，需要一定的工作經驗。
4 如何使用：接口一定要做到單一職責。類的設計儘量做到只有一個原因引起變化。可以考慮可變因素、不可變因素和相關的收益成本比率。不一定能做到最優，但一定要向着極優設計。
里氏替換原則
1 含義：簡單來說，就是父類可以出現，那麼子類也可以出現。
2 如何使用：
- 子類必須完全實現父類的方法
- 子類可以有自己的個性，但不推薦，儘量避免子類有個性。
- 覆蓋或實現父類的方法時，輸入參數可以被放大。如果是覆蓋，子類中方法的輸入參數必須與父類中被覆寫的方法的傳入參數相同或者更寬鬆。否則，會造成子類在沒有覆寫父類的方法的前提下，子類的方法被執行，這樣會造成業務邏輯混亂。
- 覆蓋或實現父類的方法時，輸出結果可以被縮小。
依賴倒置原則
1 含義：簡單來說，就是面向接口編程。
2 好處：可擴展、易維護
3 缺點：
- 最難以實現的
- 現實生活中存在必須依賴細節的事物，要具體問題具體分析。
4 如何使用：
- 每個類儘量都有接口或者抽象類
- 變量的表面類型儘量使接口或者抽象類
- 不應該從具體類再派生出子類
- 儘量不覆寫父類的方法
- 結合里氏替換原則使用，父類可以出現，那麼子類也可以出現。
接口隔離原則
1 含義：接口儘可能細化，同時接口中的方法儘量少。
2 與單一職責原則的區別：單一職責原則要求類和接口的職責單一，注重的是職責，這是從業務邏輯上劃分，而接口隔離原則要求接口的方法儘量少。舉個例子，一個接口的職責可能包含10個方法，這10個方法放在一個接口中符合單一職責原則的，但是不符合接口隔離原則的，應該按照不同的模塊再進行切分。
3 如何正確使用：根據經驗和常識決定接口的粒度大小，接口粒度太小會造成接口數量巨大，接口粒度太大會降低靈活性。
迪米特法則
1 含義：一個類應該對自己需要耦合或調用的類知道得最少。也就是說，一個對象調用其他對象的public方法，至於public方法裏面做了什麼，一概不關心。
2 核心觀念：類間解耦，低耦合。
3 實際應用：
- 當然，這樣會產生大量的中轉類或者跳轉類，提高了系統複雜性，爲維護帶來了難度。
- 如果一個類跳轉了兩次以上才能訪問到另一個類，就需要進行重構了。
開閉原則
1 含義：一個軟件實體，如模塊、類、和函數，應該對擴展開發，對修改關閉。
一個非常虛的原則，確實六大原則中最基礎的原則，是其他5大原則的精神領袖。
2 如何將該口號應用到實際工作中：
（1）抽象約束。
- 接口和抽象類，不允許出現接口或抽象類中不存在的public方法；
- 參數類型、引用對象儘量使用接口或者抽象類，而不是實現類
- 接口和抽象類儘可能穩定，一旦確定不允許修改
（2）元數據控制模塊行爲。
元數據只用來描述環境和數據的數據，通俗來講就是配置參數，該參數可以從文件獲取，也可以從數據庫獲取。
（3）制定項目章程。對項目來說，約定優於配置。
（4）封裝變化。一，將相同的變化封裝到一個接口或者抽象類中；二，將不同的變化封裝到不同的接口或者抽象類中。23種設計模式就是從各個不同的角度對變化進行封裝。
