| 序號 |
模式名稱 |
模式描述 |
應用情境 |
例子 |
| 1 |
單例模式 (SigletonPattern) |
保證一個類僅有一個執行個體,並提供一個訪問它的全域訪問點。 |
• 單例類只能有一個執行個體。 • 單例類必須自己建立自己的唯一執行個體。 • 單例類必須給所有其它對象提供這一執行個體。 |
1、每台電腦可以有若干個印表機,但只能有一個Printer Spooler,避免兩個列印工作同時輸出到印表機。 2、一個具有自動編號主鍵的表可以有多個使用者同時使用,但資料庫中只能有一個地方分配下一個主鍵編號。否則會出現主鍵重複。 |
| 2 |
策略模式 (StrategyPattern) |
定義了演算法族分別封裝起來,讓它們之間可以互相替換,此模式讓演算法的變化獨立於使用演算法的客戶。 |
利用抽象類別和繼承類之間的繼承關係,通過多態的表現方式,通過傳入不同的繼承類,得到該類的方法實現。 |
不同崗位工資不一樣 不同的鴨子有不同的特性 |
| 3 |
觀察者模式 (ObserverPattern) |
定義了對象之間的一對多依賴,這樣一來,當一個對象改變狀態時,它的所有依賴者都會收到通知並自動更新。 |
將一個系統分割成一個一些類相互協作的類有一個不好的副作用,那就是需要維護相關對象間的一致性。我們不希望為了維持一致性而使各類緊密耦合,這樣會給維護、擴充和重用都帶來不便。觀察者就是解決這類的耦合關係的。 |
氣象預報發布/訂閱 |
| 4 |
裝飾者模式 (DecoratorPattern) |
以對用戶端透明的方式擴充項物件的功能,是繼承關係的一個替代方案。 |
1.使用對象組合的方式,做到運行時裝飾類。 2.在不修改任何底層代碼的情況下,給你的對象予新的職責。 3.可以在不使用創造更多子類的情況下,將對象的功能加以擴充。 |
孫悟空有七十二般變化,他的每一種變化都給他帶來一種附加的本領。他變成魚兒時,就可以到水裡遊泳;他變成雀兒時,就可以在天上飛行。而不管悟空怎麼變化,在二郎神眼裡,他永遠是那隻猢猻。 |
| 5 |
簡單工廠 (SimpleFactoryMethod) |
根據提供給它的資料,返回幾個可能類中的一個類的執行個體。通常它返回的類都有一個公用的父類和公用的方法。 |
工廠類含有必要的判斷邏輯,可以決定在什麼時候建立哪一個產品類的執行個體,用戶端可以免除直接建立產品對象的責任,而僅僅消費產品。簡單原廠模式通過這種做法實現了對責任的分割。 |
資料庫根據設定檔進行選擇連結 |
| 5 |
原廠模式 (FactoryMethod) |
定義一個用於建立對象的介面,讓子類決定執行個體化哪一個類。 |
核心的工廠類不再負責所有產品的建立,而是將具體建立工作交給子類去做。這個核心類僅僅負責給出具體工廠必須實現的介面,而不接觸哪一個產品類被執行個體化這種細節。這使得Factory 方法模式可以允許系統在不修改工廠角色的情況下引進新產品。 |
多資料庫根據配置選擇 |
| 6 |
建造者模式 (BuilderPattern) |
可以將一個產品的內部表象與產品的產生過程分割開來,從而可以使一個建造過程產生具有不同的內部表象的產品對象。 |
一個有待建造的產品,而對象的這些性質相當於產品的零件,建造產品的過程就是組合零件的過程。由於組合零件的過程很複雜,因此,這些零件的組合過程往往被外部化到一個稱作建造者的對象裡,建造者返還給用戶端的是一個全部零件都建造完畢的產品對象。 |
電飯鍋放進去米和水,取出香噴噴的米飯了 KFC套餐不同,組合類別相同,內容不同 |
| 7 |
原型模式 (PrototypePattern) |
通過給出一個原型對象來指明所要建立的物件類型,然後用複製這個原型對象的辦法建立出更多的同類型對象。 |
建立出更多的同類型對象 |
孫悟空拔根毫毛身外化身 |
| 8 |
命令模式 (CommandPattern) |
把一個請求或者操作封裝到一個對象中。允許系統使用不同的請求把用戶端參數化,對請求排隊或者記錄請求日誌,可以提供命令的撤銷和恢複功能。 |
命令的封裝。把發出命令的責任和執行命令的責任分割開,委派給不同的對象。請求的一方發出請求要求執行一個操作;接收的一方收到請求,並執行操作。允許請求的一方和接收的一方獨立開來,使得請求的一方不必知道接收請求的一方的介面,更不必知道請求是怎麼被接收,以及操作是否被執行、何時被執行,以及是怎麼被執行的。 |
交易管理員 |
| 9 |
適配器模式 (AdapterPattern) |
把一個類的介面變換成用戶端所期待的另一種介面,從而使原本介面不匹配而無法在一起工作的兩個類能夠在一起工作。 |
1、 系統需要使用現有的類,而此類的介面不符合系統的需要。 2、 想要建立一個可以重複使用的類,用於與一些彼此之間沒有太大關聯的一些類,包括一些可能在將來引進的類一起工作。這些源類不一定有很複雜的介面。 3、 (對對象適配器而言)在設計裡,需要改變多個已有子類的介面,如果使用類的適配器模式,就要針對每一個子類做一個適配器,而這不太實際。 |
USB轉換器 插頭轉換器 變壓器 |
| 10 |
模板模式 (TemplateMethod) |
準備一個抽象類別,將部分邏輯以具體方法以及具體構造子的形式實現,然後聲明一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以以不同的方式實現這些抽象方法,從而對剩餘的邏輯有不同的實現。 |
需要開發抽象類別和具體子類的設計師之間的協作。一個設計師負責給出一個演算法的輪廓和骨架,另一些設計師則負責給出這個演算法的各個邏輯步驟。代表這些具體邏輯步驟的方法稱做基本方法(primitive method);而將這些基本法方法總匯起來的方法叫做模版方法。 |
設計師在抽象類別定義粗的範圍,開發在繼承類編寫細化的內容。 |
| 11 |
合成模式 (Composite Pattern) |
有時又叫做部分-整體模式(Part-Whole)。合成模式將對象組織到樹結構中,可以用來描述整體與部分的關係。合成模式可以使用戶端將單純元素與複合元素同等看待。 |
用來描述整體與部分的關係。 |
樹葉-樹枝 分類樹 |
| 12 |
享元模式 (FlyweightPattern) |
以共用的方式高效地支援大量的細粒度對象。享元對象能做到共用的關鍵是區分內蘊狀態(Internal State)和外蘊狀態(External State)。 |
個體抽象出類別,將類別註冊並維護為內蘊狀態。被使用的個體稱為外蘊狀態。 |
在編輯器系統中大量使用。 IME詞庫。 |
| 13 |
代理模式(ProxyPattern) |
某一個對象提供一個代理,並由代理對象控制對原對象的引用。 |
一個人或者一個機構代表另一個人或者另一個機構採取行動。在一些情況下,一個客戶不想或者不能夠直接引用一個對象,而代理對象可以在用戶端和目標對象之間起到中介的作用。 |
負載平衡伺服器 LoadRunner類比壓力測試 WebServices機制 |
| 14 |
面板模式(FacadePattern) |
外部與一個子系統的通訊必須通過一個統一的門面(Facade)對象進行,這就是面板模式,也稱為門面模式。 |
為一個複雜子系統提供一個簡單介面 提高子系統的獨立性 在層次化結構中,可以使用 模式定義系統中每一層的入口。 |
工作流程引擎 醫院導醫員 |
| 15 |
橋接模式(BridgePattern) |
將抽象化與實現化脫耦,使得二者可以獨立地變化。 |
如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性,避免在兩個層次之間建立靜態聯絡。 設計要求實現化角色的任何改變不應當影響用戶端,或者說實現化角色的改變對用戶端是完全透明的。 一個構件有多於一個的抽象化角色和實現化角色,系統需要它們之間進行動態耦合。 雖然在系統中使用繼承是沒有問題的,但是由於抽象化角色和具體化角色需要獨立變化,設計要求需要獨立管理這兩者。 |
路由器 開關控制的電燈、電風扇 |
| 16 |
責任鏈模式(ChainOfResponsibility) |
很多個物件由每一個對象對其下家的引用而串連起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求。發出這個請求的用戶端並不知道鏈上的哪一個對象最終處理這個請求,這使得系統可以在不影響用戶端的情況下動態地重新組織鏈和分配責任。 |
責任鏈模式降低了請求的發送端和接收端之間的耦合,使多個對象都有機會處理這個請求。一個鏈可以是一條線,一個樹,也可以是一個環。 |
擊鼓傳花 |
| 17 |
訪問者模式 (VisitorPattern) |
目的是封裝一些施加於某種資料結構元素之上的操作。一旦這些操作需要修改的話,接受這個操作的資料結構則可以保持不變。 |
適用於資料結構相對未定的系統,它把資料結構和作用於結構上的操作之間的耦合解脫開,使得操作集合可以相對自由地演化。 |
泛型操作 |
| 18 |
策略模式 (StrategyPattern) |
針對一組演算法,將每一個演算法封裝到具有共同介面的獨立的類中,從而使得它們可以相互替換。策略模式使得演算法可以在不影響到用戶端的情況下發生變化。 又稱為:可插入式(Pluggable)的演算法。 準備一組演算法,並將每一個演算法封裝起來,使得它們可以互換。 |
1. 如果在一個系統裡面有許多類,它們之間的區別僅在於它們的行為,那麼使用原則模式可以動態地讓一個對象在許多行為中選擇一種行為。 2. 一個系統需要動態地在幾種演算法中選擇一種。那麼這些演算法可以封裝到一個個的具體演算法類裡面,而這些具體演算法類都是一個抽象演算法類的子類。換言之,這些具體演算法類均有統一的介面,由於多態性原則,用戶端可以選擇使用任何一個具體演算法類,並只持有一個資料類型是抽象演算法類的對象。 3. 一個系統的演算法使用的資料不可以讓用戶端知道。策略模式可以避免讓用戶端涉及到不必要接觸到的複雜的和只與演算法有關的資料。 4. 如果一個對象有很多的行為,如果不用恰當的模式,這些行為就只好使用多重的條件選擇語句來實現。此時,使用原則模式,把這些行為轉移到相應的具體策略類裡面,就可以避免使用難以維護的多重條件選擇語句,並體現物件導向設計的概念。 |
演算法替換 |
| 19 |
備忘錄模式 (MementoPattern) |
在不破壞封裝性的前提下,捕獲一個對象的內部狀態,並在該對象之外儲存這個狀態。這樣以後就可將該對象恢複到原先儲存的狀態。 |
1.必須儲存一個對象在某一個時刻的部分狀態,這樣以後需要時才能恢複到先前的狀態。 如果用一個介面來讓其他對象直接得到被儲存對象的內部狀態,將會暴露對象的實現細節並破壞對象的封裝性。 |
狀態記憶、恢複 |
| 20 |
中介者模式 (MediatorPattern) |
用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式地相互引用,從而使其耦合鬆散,而且可以獨立地改變它們之間的互動。 將原來兩個直接引用或者依賴的對象拆開,在中間加入一個“中介”對象,使得兩頭的對象分別和“中介”對象引用或者依賴。 |
一組對象以定義良好但是複雜的方式進行通訊,產生了混亂的依賴關係,也導致對象難以複用。 |
房屋中介、出國中介 MVC組合模式中的控制層(Control) |
| 21 |
迭代器模式 (IteratorPattern) |
|
|
|
| 22 |
解譯器模式 (InterpreterPattern) |
|
|
|
| 23 |
狀態模式 (StatePattern) |
|
|
|
| 24 |
複合模式 (CompoundPattern) |
|
|
|