設計模式，老生常談，今天總結一下設計模式的六大原則，希望能結合過往的編程經驗，對他們有一個更加深刻的認識體會。
1、單一職責原則 （Single Responsibility Principle）：一個類只負責一項職責，儘量做到類的只有一個行爲原因引起變化；
a、業務對象（BO business object）、業務邏輯（BL business logic）拆分；
分析：
我們在設計程序結構的時候，如果不注重這個原則，一個類、接口 裏面充滿了各種各樣的行爲，就會導致程序的冗餘，耦合度大增，極不利於拓展維護。
2、里氏替換原則（LSP liskov substitution principle）：子類可以擴展父類的功能，但不能改變原有父類的功能；
（目的：增強程序的健壯性）實際項目中，每個子類對應不同的業務含義，使父類作爲參數，傳遞不同的子類完成不同的業務邏輯。
分析：
- 子類必須實現父類的抽象方法，但不得重寫（覆蓋）父類的非抽象（已實現）方法。
- 子類中可以增加自己特有的方法。
- 當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
- 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
3、依賴倒置原則（dependence inversion principle）：面向接口編程；（通過接口作爲參數實現應用場景）
抽象就是接口或者抽象類，細節就是實現類，思考一下：我們的代碼中是否真的注意了要去“抽象”，即定義抽象類和接口。
分析：
上層模塊不應該依賴下層模塊，兩者應依賴其抽象；
抽象不應該依賴細節，細節應該依賴抽象；
接口負責定義public屬性和方法，並且申明與其他對象依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯
4、接口隔離（interface segregation principle）：建立單一接口；（擴展爲類也是一種接口，一切皆接口）
定義：
a.客戶端不應該依賴它不需要的接口；
b.類之間依賴關係應該建立在最小的接口上；
分析：
接口的設計粒度越小，系統越靈活，但是靈活的同時結構複雜性提高，開發難度也會變大，維護性降低
5.迪米特原則（law of demeter LOD）：最少知道原則，儘量降低類與類之間的耦合；
一個對象應該對其他對象有最少的瞭解
分析：
這個原則，其實很好理解，我們在一個類中要儘量減少對別的類或者對象的引用，這在我們實際的編程過程中，要尤爲注意，儘量降低類與類之間的耦合，使得我們的程序易於維護。
6、開閉原則（open closed principle）：用抽象構建架構，用實現擴展原則；（總綱）
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
軟件對象（類、模塊、方法等）應該對於擴展是開放的，對修改是關閉的。
分析：
當軟件需要變化時，儘量通過擴展軟件實體的行爲來實現變化，而不是通過修改已有的代碼來實現變化。
總結：
單一職責原則告訴我們實現類要職責單一；里氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口編程；接口隔離原則告訴我們在設計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴展開放，對修改關閉。