轉自：https://blog.csdn.net/longronglin/article/details/1454315

Christopher Alexander 說過：“每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複勞動” 。 模式描述為： 在一定環境中解決某一問題的方案，包括三個基本元素--問題，解決方案和環境。 閱讀類圖和物件圖請先學習UML 建立模式 結構模式 行為模式 建立模式： 對類的例項化過程的抽象。一些系統在建立物件時，需要動態地決定怎樣建立物件，建立哪些物件，以及如何組合和表示這些物件。建立模式描述了怎樣構造和封裝這些動態的決定。包含類的建立模式和物件的建立模式。 結構模式： 描述如何將類或物件結合在一起形成更大的結構。分為類的結構模式和物件的結構模式。類的結構模式使用繼承把類，介面等組合在一起，以形成更大的結構。類的結構模式是靜態的。物件的結構模式描述怎樣把各種不同型別的物件組合在一起，以實現新的功能的方法。物件的結構模式是動態的。 行為模式： 對在不同的物件之間劃分責任和演算法的抽象化。不僅僅是關於類和物件的，並是關於他們之間的相互作用。類的行為模式使用繼承關係在幾個類之間分配行為。物件的行為模式則使用物件的聚合來分配行為。 設計模式使用排行：

頻率	所屬型別	模式名稱	模式	簡單定義
5	建立型	Singleton	單件	保證一個類只有一個例項，並提供一個訪問它的全域性訪問點。
5	結構型	Composite	組合模式	將物件組合成樹形結構以表示部分整體的關係，Composite使得使用者對單個物件和組合物件的使用具有一致性。
5	結構型	FAÇADE	外觀	為子系統中的一組介面提供一致的介面，facade提供了一高層介面，這個介面使得子系統更容易使用。
5	結構型	Proxy	代理	為其他物件提供一種代理以控制對這個物件的訪問
5	行為型	Iterator	迭代器	提供一個方法順序訪問一個聚合物件的各個元素，而又不需要暴露該物件的內部表示。
5	行為型	Observer	觀察者	定義物件間一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知自動更新。
5	行為型	Template Method	模板方法	定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，Template Method使得子類可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。
4	建立型	Abstract Factory	抽象工廠	提供一個建立一系列相關或相互依賴物件的介面，而無須指定它們的具體類。
4	建立型	Factory Method	工廠方法	定義一個用於建立物件的介面，讓子類決定例項化哪一個類，Factory Method使一個類的例項化延遲到了子類。
4	結構型	Adapter	介面卡	將一類的介面轉換成客戶希望的另外一個介面，Adapter模式使得原本由於介面不相容而不能一起工作那些類可以一起工作。
4	結構型	Decorator	裝飾	動態地給一個物件增加一些額外的職責，就增加的功能來說，Decorator模式相比生成子類更加靈活。
4	行為型	Command	命令	將一個請求封裝為一個物件，從而使你可以用不同的請求對客戶進行引數化，對請求排隊和記錄請求日誌，以及支援可撤銷的操作。
4	行為型	State	狀態	允許物件在其內部狀態改變時改變他的行為。物件看起來似乎改變了他的類。
4	行為型	Strategy	策略模式	定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。
3	建立型	Builder	生成器	將一個複雜物件的構建與他的表示相分離，使得同樣的構建過程可以建立不同的表示。
3	結構型	Bridge	橋接	將抽象部分與它的實現部分相分離，使他們可以獨立的變化。
3	行為型	China of Responsibility	職責鏈	使多個物件都有機會處理請求，從而避免請求的送發者和接收者之間的耦合關係
2	建立型	Prototype	原型	用原型例項指定建立物件的種類，並且通過拷貝這些原型來建立新的物件。
2	結構型	Flyweight	享元	享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。
2	行為型	Mediator	中介者	用一箇中介物件封裝一些列的物件互動。
2	行為型	Visitor	訪問者模式	表示一個作用於某物件結構中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用於這個元素的新操作。
1	行為型	Interpreter	直譯器	給定一個語言，定義他的文法的一個表示，並定義一個直譯器，這個直譯器使用該表示來解釋語言中的句子。
1	行為型	Memento	備忘錄	在不破壞物件的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。

  一 ： 單例模式(Singleton) 單例模式 ：Singleton的作用是保證在應用程式中，一個類Class只有一個例項存在。並提供全域性訪問。 結構： 賬本類：1 單一例項 2 給多個物件共享 3 自己建立 網頁計數器
public class LazySingleton {
     private static LazySingleton newInstance = null;   private LazySingleton () { } public static synchronized  LazySingleton getInstance () {
               if (newInstance == null) {
                newInstance = new LazySingleton ();
          }
          return newInstance;
} }
singleton 限制了例項個數，有利於gc的回收。 二： 策略模式(Strategy)    策略模式：策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會影響到環境和客戶端。 結構： 使用QQ泡MM時使用外掛  客戶端 ：ME 抽象類： 外掛 具體： 策略（圖片，笑話，名人名言） 圖書銷售演算法（不同書本折扣的演算法） 三：原型模式(Prototype) 原型模式：通過給出一個原型物件來指明所要建立的物件的型別，然後用複製這個原型物件的方法創建出更多同類型的物件。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法 結構： 影印技術： 1 不是同一個物件 2 屬同類 短訊息（轉發） 1-n個MM 因為Java中的提供clone()方法來實現物件的克隆,所以Prototype模式實現一下子變得很簡單. 四：門面模式(Façade) 門面模式：外部與一個子系統的通訊必須通過一個統一的門面物件進行。門面模式提供一個高層次的介面，使得子系統更易於使用，減少複雜性。每一個子系統只有一個門面類，而且此門面類只有一個例項，也就是說它是一個單例模式。但整個系統可以有多個門面類。 1 門面角色 2 子系統角色 結構: Facade 典型應用就是資料庫JDBC的應用和Session的應用 ME--- à MM--- à (father,mum,sister,brother) 五：備忘錄模式(Memento) Memento 模式：Memento物件是一個儲存另外一個物件內部狀態拷貝的物件，這樣以後就可以將該物件恢復到原先儲存的狀態。模式的用意是在不破壞封裝的條件下，將一個物件的狀態捕捉住，並外部化，儲存起來，從而可以在將來合適的時候把這個物件還原到儲存起來的狀態。模式所涉及的角色有三個，備忘錄角色、發起人角色和負責人角色。 備忘錄角色的作用： （1）  將發起人物件的內部狀態儲存起來，備忘錄可以根據發起人物件的判斷來決定儲存多少發起人物件的內部狀態。 （2）  備忘錄可以保護其內容不被髮起人物件之外的任何物件所讀取。 發起人角色的作用： （1）  建立一個含有當前內部狀態的備忘錄物件。 （2）  使用備忘錄物件儲存其內部狀態。 負責人角色的作用： （1）  負責儲存備忘錄物件。 （2）  不檢查備忘錄物件的內容 結構： 備份系統時使用 GHOST 六 ： 命令模式（Command） 命令模式：命令模式把一個請求或者操作封裝到一個物件中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的物件。命令模式允許請求的一方和傳送的一方獨立開來，使得請求的一方不必知道接收請求的一方的介面，更不必知道請求是怎麼被接收，以及操作是否執行，何時被執行以及是怎麼被執行的。系統支援命令的撤消。 結構：   MM （客戶端）-- à ME （請求者）-- à 命令角色-- à （具體命令）- à 代理處（接收者）-- à MM 上網 IE 輸入 http地址 傳送命令 七： 直譯器(Interpreter) 直譯器模式：給定一個語言後，直譯器模式可以定義出其文法的一種表示，並同時提供一個直譯器。客戶端可以使用這個直譯器來解釋這個語言中的句子。直譯器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在直譯器模式裡面提到的語言是指任何直譯器物件能夠解釋的任何組合。在直譯器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令物件都有一個解釋方法，代表對命令物件的解釋。命令物件的等級結構中的物件的任何排列組合都是一個語言。 結構： 編譯原理之編譯器 文言文註釋：一段文言文，將它翻譯成白話文 八：調停者模式(Mediator) 調停者模式：包裝了一系列物件相互作用的方式，使得這些物件不必相互明顯作用。從而使他們可以鬆散偶合。當某些物件之間的作用發生改變時，不會立即影響其他的一些物件之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將物件的行為和協作抽象化，把物件在小尺度的行為上與其他物件的相互作用分開處理。 結構： 法院和原告，被告的關係 九：責任鏈模式(CHAIN OF RESPONSIBLEITY) 責任鏈模式：執行者的不確定性 在責任鏈模式中，很多物件由每一個物件對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。客戶並不知道鏈上的哪一個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端物件所接受。 結構： 典型的物件結構： 喝酒時通過成語接龍決定誰喝酒(馬到成功－功不可沒－沒完沒了) 十：工廠模式（Factory） 工廠模式 ： 定義一個用於建立物件的介面，讓介面子類通過工廠方法決定例項化哪一個類。 結構： 水果園—〉（葡萄園，蘋果園）--〉（葡萄，蘋果）（各自生產） 十一：抽象工廠模式（Abstract Factory） 抽象工廠模式： 提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。 結構： 女媧造人---〉（陰，陽）--〉（人，獸）----〉（男人，女人，公獸，母獸）(人和獸屬於不同的產品類) 十二：建造模式（Builder） 建造模式：將一個複雜物件的構建與它的表示分離,使得同樣的構建過程可以建立不同的表示.Builder模式是一步一步建立一個複雜的物件,它允許使用者可以只通過指定複雜物件的型別和內容就可以構建它們.使用者不知道內部的具體構建細節.Builder模式是非常類似抽象工廠模式,細微的區別大概只有在反覆使用中才能體會到。 將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品物件。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。 結構： 互動圖：

 

 

汽車製造 十三：合成模式（ Composite ） 合成模式 ： 將物件以樹形結構組織起來,以達成“部分－整體” 的層次結構，使得客戶端對單個物件和組合物件的使用具有一致性. 合成模式就是一個處理物件的樹結構的模式。合成模式把部分與整體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分物件和由他們複合而成的合成物件同等看待。 結構： windows 的目錄樹（檔案系統） 十四： 裝飾模式（DECORATOR） 裝飾模式：裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個物件增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。 使用Decorator的理由是:這些功能需要由使用者動態決定加入的方式和時機.Decorator提供了"即插即用"的方法,在執行期間決定何時增加何種功能. 結構： 在visio中檔案可以使用背景進行裝飾 變廢為寶 十五： 設計模式之Adapter(介面卡)      介面卡模式: 把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據引數返還一個合適的例項給客戶端
將兩個不相容的類糾合在一起使用，屬於結構型模式,需要Adaptee(被適配者)和Adaptor(介面卡)兩個身份. 為何使用?
我們經常碰到要將兩個沒有關係的類組合在一起使用,第一解決方案是：修改各自類的介面，但是如果我們沒有原始碼，或者，我們不願意為了一個應用而修改各自的介面。 怎麼辦? 使用Adapter，在這兩種介面之間建立一個混合介面(混血兒). 如何使用?
實現Adapter方式,其實"think in Java"的"類再生"一節中已經提到,有兩種方式：組合(composition)和繼承(inheritance). 結構： 物件結構： 充電器（手機和220V電壓） jdbc-odbc 橋 十六：橋樑模式（Bridge） 橋樑模式：將抽象化與實現化脫耦，使得二者可以獨立的變化。也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以獨立的變化。 結構： jdbc 驅動程式 十七：代理模式（Proxy） 代理模式：代理模式給某一個物件提供一個代理物件，並由代理物件控制對源物件的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。某些情況下，客戶不想或者不能夠直接引用一個物件，代理物件可以在客戶和目標物件直接起到中介的作用。客戶端分辨不出代理主題物件與真實主題物件。代理模式可以並不知道真正的被代理物件，而僅僅持有一個被代理物件的介面，這時候代理物件不能夠建立被代理物件，被代理物件必須有系統的其他角色代為建立並傳入。 結構： 執行時的代理結構： 用代理伺服器連接出網 銷售代理（廠商）律師代理（客戶） foxmail 槍手 十八：享元模式（Flyweight） 享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類裡剔除出去。客戶端不可以直接建立被共享的物件，而應當使用一個工廠物件負責建立被共享的物件。享元模式大幅度的降低記憶體中物件的數量。 結構： 共享方法： 字型的26個字母和各自的斜體等 十九：狀態模式（State） 狀態模式：狀態模式允許一個物件在其內部狀態改變的時候改變行為。這個物件看上去象是改變了它的類一樣。狀態模式把所研究的物件的行為包裝在不同的狀態物件裡，每一個狀態物件都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個物件在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。 結構： 人心情不同時表現不同有不同的行為 編鐘 登入login logout 二十： 觀察者模式（Observer） 觀察者模式：觀察者模式定義了一種一隊多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態上發生變化時，會通知所有觀察者物件，使他們能夠自動更新自己。釋出訂閱。 結構： 公司郵件系統[email protected]的應用。當公司員工向這個郵箱發郵件時會發給公司的每一個員工。如果設定了Outlook則會及時收到通知。 接收到短訊息 二十一： 模板方法模式（Template） 模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後宣告一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。 結構： 使用網頁設計時使用的 模板架構網頁（骨架） 演算法的各個邏輯系統 二十二：訪問者模式（Visitor） 訪問者模式：訪問者模式的目的是封裝一些施加於某種資料結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的資料結構可以保持不變。訪問者模式適用於資料結構相對未定的系統，它把資料結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者物件中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡可能多的物件瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬於不同的等級結構的成員類。 結構： 電腦銷售系統： 訪問者（自己）---〉電腦配置系統（主機板，CPU，記憶體。。。。。。） 二十三：迭代子模式（Iterator） 迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個物件聚在一起形成的總體稱之為聚集，聚集物件是能夠包容一組物件的容器物件。迭代子模式將迭代邏輯封裝到一個獨立的子物件中，從而與聚集本身隔開。迭代子模式簡化了聚集的介面。每一個聚集物件都可以有一個或一個以上的迭代子物件，每一個迭代子的迭代狀態可以是彼此獨立的。迭代演算法可以獨立於聚集角色變化。 結構： 查詢資料庫，返回結果集（map， list， set） 二十四：MVC模式 MVC 模式：它強制性的使應用程式的輸入、處理和輸出分開。使用MVC應用程式被分成三個核心部件：模型、檢視、控制器。它們各自處理自己的任務。相互通訊。 MVC 還使用了的設計模式，如：用來指定檢視預設控制器的 Factory Method 和用來增加檢視滾動的Decorator。但是 MVC 的主要關係還是由 Observer 、 Composite 和 Strategy 三個設計模式給出的。   struts 圖解：其中不同顏色代表MVC的不同部分：紅色（控制器）、紫色（模型）和綠色（檢視） struts 應用 spring 應用   設計模式的使用：  

 

模式關係圖:       個人圖解：（^_^）沒有看到下面的圖解時想的 門面模式可以使用一個單體例項物件實現 抽象工廠可以建立單體例項 也可以使用工廠方法也可以使用原型建立物件例項 模板方法可以使用工廠方法實現建立例項使用 策略模式定義演算法使用 策略模式可以使用享元例項 與裝飾模式可以相互使用 享元模式被狀態，直譯器，合成等模式。共享 直譯器模式通過訪問模式實現其動作 通過享元實現基本元素的共享 裝飾模式使用策略可以實現不同的裝飾效果 迭代器模式通過訪問者訪問物件元素 通過備忘錄模式實現紀錄的記憶功能 訪問合成的物件 命令模式通過使用備忘錄模式（參考） 執行命令 建造模式可以使用合成模式建立合成產品 責任鏈模式使用合成模式定義鏈 調停者模式可以使觀察者的觀察受其影響       實際圖解：

關模式（相互關係）：

Abstract Factory 類通常用工廠方法（ Factory Method ）實現，但它們也可以用Prototype實現。一個具體的工廠通常是一個單件 Singleton 。 Abstract Factory 與Builder相似，因為它也可以建立複雜物件。主要的區別是Builder模式著重於一步步構造一個複雜物件。而 Abstract Factory 著重於多個系列的產品物件（簡單的或是複雜的）。Builder在最後一步返回產品，而對於 Abstract Factory 來說，產品是立即返回的。Composite通常是用Builder生成的。 Factory 方法通常在 Template Methods 中被呼叫。Prototype s 不需要建立Creator的子類。但是，它們通常要求一個針對Product類的Initialize操作。Creator使用Initialize來初始化物件。 Factory Method 不需要這樣的操作。多型迭代器靠 Factory Method 來例化適當的迭代器子類。 Factory Method 模式常被模板方法呼叫。 Prototype 和 Abstract Factory 模式在某種方面是相互競爭的。但是它們也可以一起使用。 Abstract Factory 可以儲存一個被克隆的原型的集合，並且返回產品物件。大量使用Composite和Decorator模式的設計通常也可從Prototype模式處獲益。 很多模式可以使用 Singleton 模式實現。參見 Abstract Factory 、Builder，和Prototype。 模式 Bridge 的結構與物件介面卡類似，但是 Bridge 模式的出發點不同； Bridge 目的是將介面部分和實現部分分離，從而對它們可以較為容易也相對獨立的加以改變。而 Adapter 則意味著改變一個 已有 物件的介面。 Decorator 模式增強了其他物件的功能而同時又不改變它的介面。因此 Decorator 對應用程式的透明性比介面卡要好。結果是 Decorator 支援遞迴組合，而純粹使用介面卡是不可能實現這一點的。模式 Proxy 在不改變它的介面的條件下，為另一個物件定義了一個代理。 Abstract Factory 模式可以用來建立和配置一個特定的Bridge模式。 Adapter 模式用來幫助無關的類協同工作，它通常在系統設計完成後才會被使用。然而，Bridge模式則是在系統開始時就被使用，它使得抽象介面和實現部分可以獨立進行改變。介面卡 Adapter 為它所適配的物件提供了一個不同的介面。相反，代理提供了與它的實體相同的介面。然而，用於訪問保護的代理可能會拒絕執行實體會執行的操作，因此，它的介面實際上可能只是實體介面的一個子集。 Decorator 模式經常與Composite模式一起使用。當裝飾和組合一起使用時，它們通常有一個公共的父類。因此裝飾必須支援具有 Add 、 Remove 和 GetChild 操作。 Decorator 模式不同於 Adapter 模式，因為裝飾僅改變物件的職責而不改變它的介面；而介面卡將給物件一個全新的介面。Composite模式可以將裝飾視為一個退化的、僅有一個元件的組合。然而，裝飾僅給物件新增一些額外的職責—它的目的不在於物件聚集。用一個裝飾你可以改變物件的外表；而Strategy模式使得你可以改變物件的核心。這是改變物件的兩種途徑。 儘管 Decorator 的實現部分與 Proxy 相似，但 Decorator 的目的不一樣。 Decorator 為物件新增一個或多個功能，而代理則控制對物件的訪問。代理的實現 Decorator 的實現類似，但是在相似的程度上有所差別。 Protection Proxy 的實現可能與 Decorator 的實現差不多。另一方面， Remote Proxy 不包含對實體的直接引用，而只是一個間接引用，如“主機 I D ，主機上的區域性地址。” Virtual Proxy 開始的時候使用一個間接引用，例如一個檔名，但最終將獲取並使用一個直接引用。 Abstract Factory 模式可以與 Facade 模式一起使用以提供一個介面，這一介面可用來以一種子系統獨立的方式建立子系統物件。 Abstract Factory 也可以代替Facade模式隱藏那些與平臺相關的類。 Mediator 模式與Facade模式的相似之處是，它抽象了一些已有的類的功能。然而， Mediator 的目的是對同事之間的任意通訊進行抽象，通常集中不屬於任何單個物件的功能。 Mediator 的同事物件知道中介者並與它通訊，而不是直接與其他同類物件通訊。相對而言，Facade模式僅對子系統物件的介面進行抽象，從而使它們更容易使用；它並不定義新功能，子系統也不知道Facade的存在。通常來講，僅需要一個Facade物件，因此Facade物件通常屬於 Singleton 模式 Chain of Responsibility 常與 Composite 一起使用。這種情況下，一個構件的父構件可作為它的後繼。 Composite 抽象語法樹是一個複合模式的例項。Composite模式可被用來實現巨集命令。 Memento 可用來保持某個狀態，命令用這一狀態來取消它的效果。在被放入歷史表列前必須被拷貝的命令起到一種原型的作用。 Memento 常與迭代器模式一起使用。迭代器可使用一個 Memento 來捕獲一個迭代的狀態。迭代器在其內部儲存 Memento 。 Flyweight 說明了如何在抽象語法樹中共享終結符。 Iterator 直譯器可用一個迭代器遍歷該結構。 Visitor 可用來在一個類中維護抽象語法樹中的各節點的行為。訪問者可以用於對一個由Composite模式定義的物件結構進行操作。迭代器常被應用到象複合這樣的遞迴結構上。 Facade 與中介者的不同之處在於它是對一個物件子系統進行抽象，從而提供了一個更為方便的介面。它的協議是單向的，即Facade物件對這個子系統類提出請求，但反之則不行。相反， Mediator 提供了各Colleague物件不支援或不能支援的協作行為，而且協議是多向的。Colleague可使用Observer模式與 Mediator 通訊。 Command 命令可使用備忘錄來為可撤消的操作維護狀態。如前所述備忘錄可用於迭代 。 Mediator 通過封裝複雜的更新語義。 Singleton 使用 Singleton 模式來保證它是唯一的並且是可全域性訪問的。 Flyweight 解釋了何時以及怎樣共享狀態物件。狀態物件通常是 Singleton 。Strategy物件經常是很好的輕量級物件。 Strategy 模板方法使用繼承來改變演算法的一部分。Strategy使用委託來改變整個演算法。 Interpreter 訪問者可以用於解釋。   建立型模式的討論 用一個系統建立的那些物件的類對系統進行引數化有兩種常用方法。一種是生成建立物件的類的子類；這對應於使用 Factory Method 模式。這種方法的主要缺點是，僅為了改變產品類，就可能需要建立一個新的子類。這樣的改變可能是級聯的（Cascade）。例如，如果產品的建立者本身是由一個工廠方法建立的，那麼你也必須重定義它的建立者。另一種對系統進行引數化的方法更多的依賴於物件複合：定義一個物件負責明確產品物件的類，並將它作為該系統的引數。這是 Abstract Factory 、Builder和Prototype模式的關鍵特徵。所有這三個模式都涉及到建立一個新的負責建立產品物件的“工廠物件”。 Abstract Factory 由這個工廠物件產生多個類的物件。Builder由這個工廠物件使用一個相對複雜的協議，逐步建立一個複雜產品。 P rototype 由該工廠物件通過拷貝原型物件來建立產品物件。在這種情況下，因為原型負責返回產品物件，所以工廠物件和原型是同一個物件。   結構型模式的討論 你可能已經注意到了結構型模式之間的相似性，尤其是它們的參與者和協作之間的相似性。這可能是因為結構型模式依賴於同一個很小的語言機制集合構造程式碼和物件：單繼承和多重繼承機制用於基於類的模式，而物件組合機制用於物件式模式。但是這些相似性掩蓋了這些模式的不同意圖。在本節中，我們將對比這些結構型模式，使你對它們各自的優點有所瞭解。 Adapter 與 Bridge Adapter 模式和 Bridge 模式具有一些共同的特徵。它們都給另一物件提供了一定程度上的間接性，因而有利於系統的靈活性。它們都涉及到從自身以外的一個介面向這個物件轉發請求。這些模式的不同之處主要在於它們各自的用途。 Bridge 模式主要是為了解決兩個已有介面之間不匹配的問題。它不考慮這些介面是怎樣實現的，也不考慮它們各自可能會如何演化。這種方式不需要對兩個獨立設計的類中的任一個進行重新設計，就能夠使它們協同工作。另一方面， Bridge 模式則對抽象介面與它的（可能是多個）實現部分進行橋接。雖然這一模式允許你修改實現它的類，它仍然為使用者提供了一個穩定的介面。 Bridge 模式也會在系統演化時適應新的實現。由於這些不同點， Adapter 和 Bridge 模式通常被用於軟體生命週期的不同階段。當你發現兩個不相容的類必須同時工作時，就有必要使用 Adapter 模式，其目的一般是為了避免程式碼重複。此處耦合不可預見。相反， Bridge 的使用者必須事先知道：一個抽象將有多個實現部分，並且抽象和實現兩者是獨立演化的。 Adapter 模式在類已經設計好 後 實施；而 Bridge 模式在設計類之 前 實施。這並不意味著 Adapter 模式不如 Bridge 模式，只是因為它們針對了不同的問題。你可能認為facade是另外一組物件的介面卡。但這種解釋忽視了一個事實：即facade定義一個 新的 介面，而 Adapter 則複用一個原有的介面。記住，介面卡使兩個 已有的 介面協同工作，而不是定義一個全新的介面。 Composite 、 Decorator 與 Proxy Composite 模式和 Decorator 模式具有類似的結構圖，這說明它們都基於遞迴組合來組織可變數目的物件。這一共同點可能會使你認為， Decorator 物件是一個退化的 Composite ，但這一觀點沒有領會 Decorator 模式要點。相似點僅止於遞迴組合，同樣，這是因為這兩個模式的目的不同。 Decorator 旨在使你能夠不需要生成子類即可給物件新增職責。這就避免了靜態實現所有功能組合，從而導致子類急劇增加。 Composite 則有不同的目的，它旨在構造類，使多個相關的物件能夠以統一的方式處理，而多重物件可以被當作一個物件來處理。它重點不在於修飾，而在於表示。儘管它們的目的截然不同，但卻具有互補性。因此 Composite 和 Decorator 模式通常協同使用。在使用這兩種模式進行設計時，我們無需定義新的類，僅需將一些物件插接在一起即可構建應用。這時系統中將會有一個抽象類，它有一些 Composite 子類和 Decorator 子類，還有 一些實現系統的基本構建模組。此時， composites 和 decorator 將擁有共同的介面。從 Decorator 模式的角度看， Composite 是一個 ConcreteComponet 。 而從 Composite 模式的角度看， Decorator 則是一個 leaf 。當然，他們不一定要同時使用，正如我們所見，它們的目的有很大的差別。 另一種與 Decorator 模式結構相似的模式是 Proxy 這兩種模式都描述了怎樣為物件提供一定程度上的間接引用， proxy 和 Decorator 物件的實現部分都保留了指向另一個物件的指標，它們向這個物件傳送請求。然而同樣，它們具有不同的設計目的。像 Decorator 模式一樣， Proxy 模式構成一個物件併為使用者提供一致的介面。但與 Decorator 模式不同的是， Proxy 模式不能動態地新增或分離性質，它也不是為遞迴組合而設 計的。它的目的是，當直接訪問一個實體不方便或不符合需要時，為這個實體提供一個替代者，例如，實體在遠端裝置上，訪問受到限制或者實體是持久儲存的。在 Proxy 模式中，實體定義了關鍵功能，而 Proxy 提供（或拒絕）對它的訪問。在 Decorator 模式中，元件僅提供了部分功能，而一個或多個 Decorator 負責完成其他功能。 Decorator 模式適用於編譯時不能（至少不方便）確定物件的全部功能的情況。這種開放性使 遞迴組合成為 Decorator 模式中一個必不可少的部分。而在 Proxy 模式中則不是這樣，因為 Proxy 模式強調一種