【設計模式】設計模式總覽
阿新 • • 發佈:2018-07-24
工廠方法模式 通信 工廠模式 變化 適配 解釋器 展開 必須 們的 單一職責原則
開放封閉原則
裏氏代替原則
依賴倒置原則
設計模式
1. 創建型模式(6種)
創建對象時,不再由我們直接實例化對象;而是根據特定場景,由程序來確定創建對象的方式,從而保證更大的性能、更好的架構優勢。
-
簡單工廠模式(不是之一)
-
工廠方法模式
-
抽象工廠模式
-
原型模式
-
建造者模式
-
單例模式
2. 結構型模式(7種)
用於幫助將多個對象組織成更大的結構。
-
外觀模式
-
適配器模式
-
代理模式
-
裝飾模式
-
橋接模式
-
組合模式
-
享元模式
3.行為型模式(11種)
用於幫助系統間各對象的通信,以及如何控制復雜系統中流程。
-
模版方法模式
-
觀察者模式
-
狀態模式
-
策略模式
-
職責鏈模式
-
命令模式
-
訪問者模式
-
調停者模式
-
備忘錄模式
-
叠代器模式
-
解釋器模式
設計模式六大原則
單一職責原則
一個類=只有一個引起它變化的原因。
如果一個類承擔的職責過多,即耦合性太高=一個職責的變化可能會影響到其他的職責
開放封閉原則
一個實體(類、函數、模塊等)應該對外擴展開放,對內修改關閉
- 即每次發生變化時,要通過添加新的代碼來增強現有類型的行為,而不是修改原有的代碼。
- 符合開放封閉原則的最好方式是提供一個固有的接口,然後讓所有可能發生變化的類實現該接口,讓固定的接口與相關對象進行交互。
裏氏代替原則
子類必須替換掉它們的父類型。
- 在軟件開發過程中,子類替換父類後,程序的行為是一樣的。
- 只有當子類替換掉父類後軟件的功能不受影響時,父類才能真正地被復用,而子類也可以在父類的基礎上添加新的行為。
依賴倒置原則
細節應該依賴於抽象,而抽象不應該依賴於細節。
所謂的的 “面向接口編程,而不是面向實現編程”。這樣可以降低客戶與具體實現的耦合。
接口隔離原則
使用多個專門功能的接口,而不是使用單一的總接口。
不要讓一個單一的接口承擔過多的職責,而應把每個職責分離到多個專門的接口中,進行接口分離。
合成復用原則
在一個新的對象裏面使用一些已有的對象,使之成為新對象的一部分。
新對象通過向這些對象的委派達到復用已用功能的目的。簡單地說,就是要盡量使用合成/聚合,盡量不要使用繼承。
最少知識原則(迪米特法則)
一個模塊或對象應盡量少的與其他實體之間發生相互作用,使得系統功能模塊相對獨立,這樣當一個模塊修改時,影響的模塊就會越少,擴展起來更加容易。
- 關於迪米特法則的其他描述:只與你直接的朋友們通信;不要跟“陌生人”說話。
- 外觀模式(Facade Pattern)和中介者模式(Mediator Pattern)就使用了迪米特法則。
【設計模式】設計模式總覽