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

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）

單一職責原則：類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 介面合并：如果一個業務包含多個固定步驟，我們不應該把步驟都暴露，而是提供一個入口即可；如地圖導航，里面有搜索-定位-導航介面，對于用戶只要結果導航，所以要把三個介面合并；