1. 單一職責原則（SRP）（Single Responsibility Principle）
2. 里氏替換原則（LSP）（Liskov Substitution Principle）
3. 依賴倒置原則（DIP）（Dependence Inversion Principle）
4. 接口隔離原則（ISP）（Interface Segregation Principle）
5. 迪米特原則（LOD）（Law Of Demeter）
6. 開閉原則（OCP）（Open Closed Principle）
1：單一職責原則（一個類只做一件事）
應用場景：
類T負責兩個不同的職責：P1職責，P2職責。當P1需求發生變法時而需要修改類T時，就有可能導致原本運行正常的P2發生故障。
遵循單一原則，把P1跟P2分成兩個類，每個類只關注一件事情避免因為需求的修改而引發不必要的故障
什么情況下可以違背單一職責原則：
只要邏輯足夠簡單，就可以在方法級別上違背單一職責原則
如果一個類足夠簡單，方法夠少，就可以在類級別上違背單一職責原則
雜話：各種級別（方法/類/接口/類庫/項目/系統）
優點：
1 類邏輯變得簡單
2 代碼穩定，可擴展性高
缺點：
1 代碼會變多
2：里氏替換原則（任何使用基類的地方，其子類都可以透明的使用（繼承，多態））
如果子類不能擁有父類的全部屬性和行為，斷掉繼承
如果子類要修改父類的行為，使用override/virtual
總結來說，里氏替換原則就是規范了繼承的使用
3：依賴倒置原則（上層模塊不直接依賴下層模塊，二者應通過抽象依賴（抽象類/接口類））
依賴抽象（抽象類/接口類），而不是依賴細節（實現類）
相對於細節，依賴抽象更穩定
基於抽象的架構，更穩定
雜談：經常聽到的幾個詞
1 控制反轉（IOC）：把依賴交給第三方容器來完成 （目的）
2 依賴注入（DI）：實現控制反轉的一種手段 （行為）
4：接口隔離原則（客戶端不應該依賴於它不需要的接口，一個類對另一個類的的依賴應該建立在最小的接口上）
不要使用大而全的接口，這樣導致實現不需要的方法
也不能拆分的太細，這樣會導致使用不便
關於接口隔離原則，具體情況還需要根據業務需求來定，沒有一個同一標准，該拆該合，都得需要自己度量
5：迪米特法則（最少知道原則）（一個對象只於關系最密切的朋友進行通訊，高內聚，低耦合）
類於類之前，要避免不必要的依賴
學校，老師，班級，學生四個類
學校只與老師通訊，老師只跟班級通訊，不要學校在關聯老師的同時，又關聯班級，這樣會增加依賴、
場景：老師類中有一個班級的集合，班級類中有一個學生的集合
錯誤做法：在老師類中寫一個方法，遍歷出所有班級，在遍歷中，又根據班級遍歷出所有學生（這種寫法雖然很爽，但是增加了不必要的依賴）
正確做法：在老師類中寫一個方法，在班級類中寫一個方法，老師類中遍歷出所有班級，在遍歷中在根據班級調用班級類中自身的方法獲取所有的學生（減少了不必要的依賴）
雜談：類與類的關系
縱向關系：繼承 實現
橫向關系：依賴（方法內部） 關聯 組合 聚合（后三個：方法返回/參數 屬性）
6：開閉原則（開放擴展，關閉修改）
沒有任何的指導意義，只能算是一個願景，架構的最理想狀態
其他五個原則，都是為了輔助開閉原則，從而達到真正的理想狀態
總結
1：六大原則並不是指具體的技術或者應用，而是一個指導性的原則，如何遵循六大原則需要自己度量，相當於一個建議，並不一定必須遵守六大原則，根據業務需求，自己做取舍
2：真正的業務需求中，往往會出現遵循了這個原則，卻違反了另一個原則，具體側重哪個原則，還要根據業務需求來定，不要盲目的追求。
3：盡可能的遵循六大原則來寫代碼，使你的應用變得健壯，擴展性高，易維護。