設計模式六大原則： 面向對象語言開發過程中，推薦的一些指導性原則(並不是強制要求的)

1. 單一職責原則（Single Responsibility Principle）
2. 里氏替換原則（Liskov Substitution Principle）
3. 依賴倒置原則（Dependence Inversion Principle）
4. 介面隔離原則（Interface Segregation Principle）
5. 迪米特法則 （Law Of Demeter）
6. 開閉原則(Open Closed Principle)

1.單一職責原則（Single Responsibility Principle）

1. 單一職責原則：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。

簡單來說單一職責原則就是：一個類只負責一件事兒，一個類不要讓他太“累” ；

優點：拆分之後，職責變得單一
          閱讀簡單，易於維護；
          擴展升級，減少修改，直接增加類；
          方便代碼重用的；
          總的來說就是使程式：簡單--穩定--強大

缺點：單一職責的成本：類變多了；上端需要瞭解更多的類

衡量著使用：如果類相對穩定，擴展變化少，而且邏輯簡單，違背單一職責也沒關係

                     代碼足夠簡單，就可以稍稍違背；
                     如果不同的職責，總是一起變化，這種是一定要分開的；
 
當然不只是類要支持單一職責原則，下麵這些也要支持：

方法：方法多個分支，還可能擴展變化，最好拆分成多個方法；
類：接受輸入-數據驗證-邏輯計算--資料庫操作--日誌 為了重用，方便維護升級；
介面：也會把不同的功能介面，獨立開來；
類庫：把項目拆分成多個類庫，重用--方便維護；
項目：一個web解決所有問題：客戶端；管理後臺；定時服務；遠程介面； 還是要拆分；
系統：成熟互聯網企業，有N多項目，有很多重覆功能，IP庫/日誌庫/監控系統/線上統計。。。；

2. 里氏替換原則（Liskov Substitution Principle）

里氏替換原則：任何使用基類的地方，都可以透明的使用其子類；也就是，繼承+不改變行為；

繼承：通過繼承，子類擁有父類的一切屬性和行為，任何父類出現的地方，都可以用子類來代替；
1 子類必須完全實現父類有的方法,如果子類沒有父類的某項東西，就斷掉繼承；
2 子類可以有父類沒有的東西，所以子類的出現的地方，不一定能用父類來代替；
3 透明，就是安全，父類的東西換成子類後不影響程式：
     a 父類已經實現的東西，子類不要去new；
     b 父類已經實現的東西，想改的話，就必須用virtual+override 避免埋雷；

  聲明變數、參數、屬性、欄位，最好都是基於基類的，也就是里式替換原則，能在父類聲明的東西不要在子類聲明；

3. 依賴倒置原則（Dependence Inversion Principle）

依賴倒置原則:高層模塊不應該依賴於低層模塊，二者應該通過抽象依賴，也就是要依賴抽象，而不是依賴細節；

抽象：抽象類/介面
細節：具體的類

23種設計模式，80%以上跟這個有關

依賴細節：程式寫死了，不談什麼擴展；
依賴抽象，更具有通用性，而且具備擴展性；
細節多變的，抽象是穩定的；系統架構基於抽象來搭建，會更穩定更具備擴展性

面向抽象編程， 底層模塊裡面儘量都有抽象類/介面，
在聲明參數/變數/屬性的時候，儘量的都是 介面/抽象類

有人說：你說的我都懂，但是我在開發的過程中，好像沒有感覺哪裡需要抽象？
    其實是因為你的項目還不夠麻煩，，如果項目不考慮擴展變化，那確實不需要依賴倒置

4. 介面隔離原則（Interface Segregation Principle）

介面隔離原則:客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上；
                       實現一個介面的時候，只需要自己必須的功能；

為什麼不建立一個大而全的介面，而是要拆分？

因為不能讓類型實現自己沒有的功能；

為什麼要儘量的用同一個介面？

儘量讓抽象更具備復用性；

介面拆分是隨著項目進程而演變的，一直演變下去，是不是直接拆分成一個介面一個方法得了？？
如果真的一個介面一個方法，那也沒意義了；

究竟該如何設計呢？ 確實需要豐富的經驗和對業務的理解：
1 介面不能太大，否則會實現不需要的功能；
2 介面還是要儘量的小， 但是一致的功能是應該在一起的，密不可分的功能不要分開；
   不能過度設計 要考慮清楚業務的邊界；
3 介面合併：如果一個業務包含多個固定步驟，我們不應該把步驟都暴露，而是提供一個入口即可；如地圖導航，裡面有搜索-定位-導航介面，對於用戶只要結果導航，所以要把三個介面合併；

5. 迪米特法則 （Law Of Demeter）

迪米特法則(最少知道原則):一個對象應該對其他對象保持最少的瞭解。

面向對象--類--類與類之間會有交互--功能模塊--系統
高內聚，低耦合：高度封裝，儘量少的暴露信息，類與類之間減少依賴；
只與直接的朋友通信

去掉內部依賴--降低訪問修飾符
門面(外觀)模式/中介者模式

6. 開閉原則(Open Closed Principle)

開閉原則:對擴展開發，對修改關閉；
如果有功能擴展變化的需求，希望是增加類而不是修改；
修改會影響原有功能，引入錯誤；
增加類就不會影響原有的東西；

開閉原則是原則的原則，五大原則是手段，這個是目標；
修改方法--增加方法(修改類)--增加類--增加dll--配置文件；

當然項目設計的時候，其實很難說全部都滿足；任何一個項目都有自己的特點；
會在這裡有所取捨；