六大設計原則，按照英文首字母概括為sollid，可簡單理解為-solid-穩定的。
這六大設計原則如下：
single responsibility principle：單一職責原則
open closed principle：開閉原則
liskov substitution principle：黎克特制替換原則
law of demeter：迪公尺特法則
inte***ce segregation principle：介面隔離原則
dependence inversion principle：依賴倒置原則
1.1定義
應該有且僅有乙個原因引起類的變更。
1.2示例
iphone這個介面，並不是單一職責，而是兩個職責：乙個是協議管理-dial()和hangup()；另乙個是資料傳送-chat()。
協議接通的變化、資料傳送的變化都會引起這個介面或實現類的變化。
這兩個職責互不影響，可拆分成兩個介面。
2.1定義
乙個軟體實體，如類、模組和函式應該對擴充套件開放，對修改關閉。
直白的講：乙個軟體實體應該通過擴充套件來實現變化，而不是通過修改已有的**來實現變化。
2.2示例
書店開始打折銷售，如何應對這一變化呢？
修改介面——導致實現類novelbook和bookstore的main方法都要修改。該方案否定。
修改實現類——由於採購人員也要看**，會因資訊不對稱導致決策失誤。該方案不是最優。
*通過擴充套件實現變化——增加乙個子類offnovelbook，並覆寫getprice方法，不需修改原有**。最優方案。
3.1定義
所有引用基類的地方必須能透明地使用其子類的物件。
直白的講：只要父類能出現的地方子類就可以出現，但是反過來就不行，有子類的地方，父類未必就能適應。向下轉型是不安全的。
3.2示例
士兵使用aug狙擊槍殺敵。
正確**：
class client
}
錯誤**：
class client
}
4.1定義
也稱為最少知識原則。即：乙個物件應該對其他物件有最少的了解。
4.2示例
朋友類：出現在成員變數、成員方法的輸入輸出引數中的類稱為成員朋友類，而出現在方法體內部的類不屬於朋友類。
示例中的girl類是出現在teacher類的command方法體內，因此不屬於teacher類的朋友類。
迪公尺特法則告訴我們乙個類只和朋友類交流，teacher類卻與陌生類girl有了交流，破壞了teacher類的健壯性。
方法是類的乙個行為，類竟然不知到自己的行為與其他類產生了依賴關係，這是不允許的，嚴重違反了迪公尺特法則。
修改後的類圖如下：
5.1定義
介面盡量細化，同時介面中的方法盡量少。
5.2示例
產生了問題：氣質型girl不需要具備goodlooking以及nicefigure的。所以介面封裝過度！
修改後的類圖如下：
6.依賴倒置原則（dip）
6.1定義
*模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的；
*介面或抽象類不依賴於實現類；
*實現類依賴介面或抽象類。
6.2示例
產生了問題：driver不僅開benz還開bmw，可是driver類和benz類之間是緊耦合的關係，導致系統可維護性降低，可讀性降低。
修改後的類圖如下：
在使用的過程中遵循以下幾個規則：
*每個類盡量都有介面或抽象類，或者二者兼備
*變數的表面型別盡量是介面或者是抽象類
*任何類都不應該從具體類派生
*盡量不要覆寫基類的方法
*介面負責定義public屬性和方法，並且宣告與其他物件的依賴關係；抽象類負責公共構造部分的實現；實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化。
六大設計原則
1.單一職責原則 單一職責原則 single responsibility principle，srp 有且僅有乙個原因引起類的變更，乙個介面或類只有乙個職責。2.黎克特制替換原則 黎克特制替換原則 liskov substitution principle，lsp 所有引用基類的地方必須能透明地使...
六大設計原則
開閉原則 對擴充套件開放對修改關閉 軟體在生命週期內會發生變化，開閉原則告訴我們應該通過拓展軟體實體行為來實現變化而不是修改已有 來完成變化 改變要盡量少 變化型別 邏輯變化 子模組變化 可見檢視變化 優點 1.已有 是通過了測試的，減少了測試成本 2.提高復用性 顆粒度越小，被復用的可能性就越大，...
六大設計原則
總體遵循開閉原則 open close principle 即對擴充套件開放，對修改關閉。1 單一職責原則 不要存在多餘乙個導致類變更的原因，每個類保持單一的職責，如若不然，就需要把類拆分。2 黎克特制代換原則 liskov substitution principle 黎克特制代換原則 lisko...