設計模式是指在軟體開發中，經過驗證的，用於解決特定環境下，重複出現的，特定問題的解決方案；
經過驗證，特定環境，重複出現，這幾個性質決定了，設計模式不是一種純粹的技術，
而是一種針對特定行業，特定環境和問題的一種經驗複合體。
也決定了設計模式的掌握不是一蹴而就的。
高層模組不應該依賴低層模組，兩者都應該依賴抽象
抽象不應該依賴具體實現，具體實現應該依賴抽象
高層模組與低層模組在業務上有關聯，低層模組與高層模組都可能發生變化，
但是他們的變化都應該依賴於抽象，抽象在這裡可以被看作標準。
2.開放封閉原則
乙個類應該對擴充套件開放，對修改關閉
這裡的擴充套件開放，指的是指乙個類對外提供的介面應該具有可擴充套件性，
可以在原有的基礎上上擴充套件出更多的對外功能介面，對修改關閉是指，應保持介面功能的穩定性，不對其做輕易修改
3.面向介面程式設計
不將變數型別宣告為某個特定的類，而是宣告為某個介面
客戶程式無需獲知物件的具體型別，只需要知道物件所具有的介面
減少系統中各部分的依賴關係，從而實現「高內聚、松耦合」型別設計方案
對於不固定的型別，將其宣告為介面，可以根據變化繼承處相應變化結果的不同的具體類，從而保證了可擴充套件性
對客戶隔離物件型別，而讓其其只關注介面，客戶呼叫介面而不是呼叫具體的類，可以在一定程度上隔離類的變化對客戶的影響
減少系統中各部分之間得依賴關係，防止系統中一部分功能被修改時，其他部分不可預料得bug得出現，提高了系統得健壯性
**4.封裝變化點**
將穩定點和變化點分離，擴充套件修改變化點
如果乙個類得業務中，有變化點和穩定定，應當將變化點和穩定點隔離開，穩定點提供介面對變化點進行適應
，變化點具備可擴充套件性，方便進行擴充套件，這樣得程式在不斷得擴充套件中，也能保持很強得有序性，也增強了程式得健壯性
**5.單一職責原則**
乙個類應該僅有乙個一起它變化得原因
如果乙個類有多個職責，則不同職責之間就具有了一定得耦合性，由於職責得變化性，
其中乙個字職責得變化很可能對其他職責帶來難以預見得影響，一方面它破壞了健壯性，又破壞了它的可復用性。
**6.黎克特制替換原則**
子類必須能夠替換它的父型別
主要原因是當子類覆蓋父類的實現，卻沒有完成父類的職責，這個時候如果用子類覆蓋父類的使用，會出現錯誤。
這裡子類覆蓋父類的實現，是指子類以相同 的方法覆蓋父類同樣的方法，
改變了子類對應父類部分方法的職責導致子類無法完全 替代父類完成父類原本擁有的職責。
**7.介面隔離原則**
不應該強迫使用者依賴他們不需要的方法
如果乙個類的很多介面都以public的方式暴露給客戶，則當客戶使用是，不明白自己要使用的職責。
乙個類應該把客戶不需要的職責隱藏起來。
一般用於處理乙個類擁有比較多的介面，而這些介面設計很多職責
**8 物件組合優於類繼承**
優於繼承的耦合程度很高，使得子類的可變化學被大大的限制，使用組合時可以大大的減少耦合度，
在具體業務場景下需關注該原則
設計模式 設計模式原則
1 單一職責原則 srp 乙個類應當只有乙個引起其變化的原因。使用單一職責原則的好處有 1 類的複雜性降低 2 可讀性提高 3 可維護性提高 4 變更引起的風險降低 2 黎克特制替換原則 lsp 在使用父類的地方，可以使用其子類替換。黎克特制替換原則的含義 1 子類必須完全實現父類的方法 2 子類可...
設計模式 設計原則
1.單一職責原則 single responsibility principle，簡稱srp 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到...
設計模式 設計原則
description 這是本人學習 設計模式之禪 的筆記 設計原則 一 單一職責 應該有且僅有乙個原因讓乙個類發生變更。這個原則目的是要讓介面的職責分明，結構清晰。優點 類的複雜度降低，可讀性提高，變更風險低，可維護性提高。二 黎克特制替換 通俗一點就是父類存在的地方，可以替換為子類，而程式的行為...