設(shè)計模式匯總

一、基礎(chǔ)知識

1. 設(shè)計模式概述

定義：設(shè)計模式（Design Pattern）是一套被反復(fù)使用外臂、多數(shù)人知曉的腥泥、經(jīng)過分類編目的岩梳、代碼設(shè)計經(jīng)驗的總結(jié)，使用設(shè)計模式是為了可重用代碼猿涨、讓代碼更容易被他人理解并且保證代碼可靠性握童。

根據(jù)它們的用途，設(shè)計模式可分為 創(chuàng)建型(Creational) 叛赚， 結(jié)構(gòu)型(Structural) 和 行為型(Behavioral) 三種澡绩。其中 創(chuàng)建型模式 主要用于描述如何創(chuàng)建對象，結(jié)構(gòu)型模式 主要用于描述如何實現(xiàn)類或?qū)ο蟮慕M合俺附，行為型模式 主要用于描述類或?qū)ο笤鯓咏换ヒ约霸鯓臃峙渎氊?zé)肥卡。在 GoF 23 種設(shè)計模式中包含 5 種創(chuàng)建型設(shè)計模式、7 種結(jié)構(gòu)型設(shè)計模式和 11 種行為型設(shè)計模式事镣。此外步鉴，根據(jù)某個模式主要是用于處理類之間的關(guān)系還是對象之間的關(guān)系，設(shè)計模式還可以分為 類模式 和 對象模式 璃哟。我們經(jīng)常將兩種分類方式結(jié)合使用氛琢，如單例模式是對象創(chuàng)建型模式，模板方法模式是類行為型模式随闪。

值得一提的是阳似，有一個設(shè)計模式雖然不屬于 GoF 23 種設(shè)計模式，但一般在介紹設(shè)計模式時都會對它進行說明蕴掏，它就是 簡單工廠模式 障般，也許是太 “ 簡單 ” 了，GoF 并沒有把它寫到那本經(jīng)典著作中盛杰，不過現(xiàn)在大部分的設(shè)計模式書籍都會對它進行專門的介紹挽荡。

常用 24 種設(shè)計模式如下表所示：

2. 面向?qū)ο笤O(shè)計原則

如何同時提高一個軟件系統(tǒng)的可維護性和可復(fù)用性是面向?qū)ο笤O(shè)計需要解決的核心問題之一。在面向?qū)ο笤O(shè)計中即供，可維護性的復(fù)用是以設(shè)計原則為基礎(chǔ)的定拟。每一個原則都蘊含一些面向?qū)ο笤O(shè)計的思想，可以從不同的角度提升一個軟件結(jié)構(gòu)的設(shè)計水平。面向?qū)ο笤O(shè)計原則為支持可維護性復(fù)用而誕生青自，這些原則蘊含在很多設(shè)計模式中株依，它們是從許多設(shè)計方案中總結(jié)出的指導(dǎo)性原則。

最常見的 7 種面向?qū)ο笤O(shè)計原則如下表所示：

二荠藤、24 種設(shè)計模式簡介

1. 6 個創(chuàng)建型模式

單例模式 (Singleton Pattern)

單例模式(Singleton Pattern)：確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例获高，這個類稱為單例類哈肖，它提供全局訪問的方法。

• 單例模式確保某一個類只有一個實例念秧，而且自行實例化并向整個系統(tǒng)提供這個實例淤井，這個類稱為單例類，它提供全局訪問的方法摊趾。單例模式的要點有三個：一是某個類只能有一個實例币狠；二是它必須自行創(chuàng)建這個實例；三是它必須自行向整個系統(tǒng)提供這個實例严就。單例模式是一種對象創(chuàng)建型模式总寻。
• 單例模式只包含一個單例角色：在單例類的內(nèi)部實現(xiàn)只生成一個實例，同時它提供一個靜態(tài)的工廠方法梢为，讓客戶可以使用它的唯一實例渐行；為了防止在外部對其實例化，將其構(gòu)造函數(shù)設(shè)計為私有铸董。
• 單例模式的目的是保證一個類僅有一個實例祟印，并提供一個訪問它的全局訪問點。單例類擁有一個私有構(gòu)造函數(shù)粟害，確保用戶無法通過 new 關(guān)鍵字直接實例化它蕴忆。除此之外，該模式中包含一個靜態(tài)私有成員變量與靜態(tài)公有的工廠方法悲幅。該工廠方法負責(zé)檢驗實例的存在性并實例化自己套鹅，然后存儲在靜態(tài)成員變量中，以確保只有一個實例被創(chuàng)建汰具。
• 單例模式的主要優(yōu)點在于提供了對唯一實例的受控訪問并可以節(jié)約系統(tǒng)資源卓鹿；其主要缺點在于因為缺少抽象層而難以擴展，且單例類職責(zé)過重留荔。
• 單例模式適用情況包括：系統(tǒng)只需要一個實例對象吟孙；客戶調(diào)用類的單個實例只允許使用一個公共訪問點。

簡單工廠模式 (Simple Factory Pattern)

簡單工廠模式(Simple Factory Pattern)：定義一個工廠類，它可以根據(jù)參數(shù)的不同返回不同類的實例杰妓，被創(chuàng)建的實例通常都具有共同的父類藻治。因為在簡單工廠模式中用于創(chuàng)建實例的方法是靜態(tài)(static)方法，因此簡單工廠模式又被稱為靜態(tài)工廠方法(Static Factory Method)模式巷挥。它屬于類創(chuàng)建型模式桩卵。

• 創(chuàng)建型模式對類的實例化過程進行了抽象，能夠?qū)ο蟮膭?chuàng)建與對象的使用過程分離句各。
• 簡單工廠模式又稱為靜態(tài)工廠方法模式吸占，它屬于類創(chuàng)建型模式晴叨。在簡單工廠模式中凿宾，可以根據(jù)參數(shù)的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責(zé)創(chuàng)建其他類的實例兼蕊，被創(chuàng)建的實例通常都具有共同的父類初厚。
• 簡單工廠模式包含三個角色：工廠角色負責(zé)實現(xiàn)創(chuàng)建所有實例的內(nèi)部邏輯；抽象產(chǎn)品角色是所創(chuàng)建的所有對象的父類孙技，負責(zé)描述所有實例所共有的公共接口产禾；具體產(chǎn)品角色是創(chuàng)建目標(biāo)，所有創(chuàng)建的對象都充當(dāng)這個角色的某個具體類的實例牵啦。
• 簡單工廠模式的要點在于：當(dāng)你需要什么亚情，只需要傳入一個正確的參數(shù)，就可以獲取你所需要的對象哈雏，而無須知道其創(chuàng)建細節(jié)楞件。
• 簡單工廠模式最大優(yōu)點在于實現(xiàn)對象的創(chuàng)建和對象的使用分離，將對象的創(chuàng)建交給專門的工廠類負責(zé)裳瘪，但是其最大缺點在于工廠類不夠靈活土浸，增加新的具體產(chǎn)品需要修改工廠類的判斷邏輯代碼，而且產(chǎn)品較多時彭羹，工廠方法代碼將會非常復(fù)雜黄伊。
• 簡單工廠模式適用情況包括：工廠類負責(zé)創(chuàng)建的對象比較少；客戶端只知道傳入工廠類的參數(shù)派殷，對于如何創(chuàng)建對象不關(guān)心还最。

工廠方法模式 (Factory Method Pattern)

工廠方法模式(Factory Method Pattern)：定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實例化毡惜。工廠方法模式讓一個類的實例化延遲到其子類拓轻。工廠方法模式又簡稱為工廠模式(Factory Pattern)，又可稱作虛擬構(gòu)造器模式(Virtual Constructor Pattern)或多態(tài)工廠模式(Polymorphic Factory Pattern)虱黄。它屬于類創(chuàng)建型模式悦即。

• 工廠方法模式又稱為工廠模式，它屬于類創(chuàng)建型模式。在工廠方法模式中辜梳，工廠父類負責(zé)定義創(chuàng)建產(chǎn)品對象的公共接口粱甫，而工廠子類則負責(zé)生成具體的產(chǎn)品對象，這樣做的目的是將產(chǎn)品類的實例化操作延遲到工廠子類中完成作瞄，即通過工廠子類來確定究竟應(yīng)該實例化哪一個具體產(chǎn)品類茶宵。
• 工廠方法模式包含四個角色：抽象產(chǎn)品是定義產(chǎn)品的接口，是工廠方法模式所創(chuàng)建對象的超類型宗挥，即產(chǎn)品對象的共同父類或接口乌庶；具體產(chǎn)品實現(xiàn)了抽象產(chǎn)品接口，某種類型的具體產(chǎn)品由專門的具體工廠創(chuàng)建契耿，它們之間往往一一對應(yīng)瞒大；抽象工廠中聲明了工廠方法，用于返回一個產(chǎn)品搪桂，它是工廠方法模式的核心透敌，任何在模式中創(chuàng)建對象的工廠類都必須實現(xiàn)該接口；具體工廠是抽象工廠類的子類踢械，實現(xiàn)了抽象工廠中定義的工廠方法酗电，并可由客戶調(diào)用，返回一個具體產(chǎn)品類的實例内列。
• 工廠方法模式是簡單工廠模式的進一步抽象和推廣撵术。由于使用了面向?qū)ο蟮亩鄳B(tài)性，工廠方法模式保持了簡單工廠模式的優(yōu)點话瞧，而且克服了它的缺點嫩与。在工廠方法模式中，核心的工廠類不再負責(zé)所有產(chǎn)品的創(chuàng)建移稳，而是將具體創(chuàng)建工作交給子類去做蕴纳。這個核心類僅僅負責(zé)給出具體工廠必須實現(xiàn)的接口，而不負責(zé)產(chǎn)品類被實例化這種細節(jié)个粱，這使得工廠方法模式可以允許系統(tǒng)在不修改工廠角色的情況下引進新產(chǎn)品古毛。
• 工廠方法模式的主要優(yōu)點是增加新的產(chǎn)品類時無須修改現(xiàn)有系統(tǒng)，并封裝了產(chǎn)品對象的創(chuàng)建細節(jié)都许，系統(tǒng)具有良好的靈活性和可擴展性稻薇；其缺點在于增加新產(chǎn)品的同時需要增加新的工廠，導(dǎo)致系統(tǒng)類的個數(shù)成對增加胶征，在一定程度上增加了系統(tǒng)的復(fù)雜性塞椎。
• 工廠方法模式適用情況包括：一個類不知道它所需要的對象的類；一個類通過其子類來指定創(chuàng)建哪個對象睛低；將創(chuàng)建對象的任務(wù)委托給多個工廠子類中的某一個案狠，客戶端在使用時可以無須關(guān)心是哪一個工廠子類創(chuàng)建產(chǎn)品子類服傍，需要時再動態(tài)指定。

抽象工廠模式 (Abstract Factory Pattern)

抽象工廠模式(Abstract Factory Pattern)：提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口骂铁，而無須指定它們具體的類吹零。抽象工廠模式又稱為Kit模式，屬于對象創(chuàng)建型模式拉庵。

• 抽象工廠模式包含四個角色：抽象工廠用于聲明生成抽象產(chǎn)品的方法灿椅；具體工廠實現(xiàn)了抽象工廠聲明的生成抽象產(chǎn)品的方法，生成一組具體產(chǎn)品钞支，這些產(chǎn)品構(gòu)成了一個產(chǎn)品族茫蛹，每一個產(chǎn)品都位于某個產(chǎn)品等級結(jié)構(gòu)中；抽象產(chǎn)品為每種產(chǎn)品聲明接口烁挟，在抽象產(chǎn)品中定義了產(chǎn)品的抽象業(yè)務(wù)方法婴洼；具體產(chǎn)品定義具體工廠生產(chǎn)的具體產(chǎn)品對象，實現(xiàn)抽象產(chǎn)品接口中定義的業(yè)務(wù)方法信夫。
• 抽象工廠模式是所有形式的工廠模式中最為抽象和最具一般性的一種形態(tài)窃蹋。抽象工廠模式與工廠方法模式最大的區(qū)別在于，工廠方法模式針對的是一個產(chǎn)品等級結(jié)構(gòu)静稻，而抽象工廠模式則需要面對多個產(chǎn)品等級結(jié)構(gòu)。
• 抽象工廠模式的主要優(yōu)點是隔離了具體類的生成匈辱，使得客戶并不需要知道什么被創(chuàng)建振湾，而且每次可以通過具體工廠類創(chuàng)建一個產(chǎn)品族中的多個對象，增加或者替換產(chǎn)品族比較方便亡脸，增加新的具體工廠和產(chǎn)品族很方便押搪；主要缺點在于增加新的產(chǎn)品等級結(jié)構(gòu)很復(fù)雜，需要修改抽象工廠和所有的具體工廠類浅碾，對“開閉原則”的支持呈現(xiàn)傾斜性大州。
• 抽象工廠模式適用情況包括：一個系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實例如何被創(chuàng)建、組合和表達的細節(jié)垂谢；系統(tǒng)中有多于一個的產(chǎn)品族厦画，而每次只使用其中某一產(chǎn)品族；屬于同一個產(chǎn)品族的產(chǎn)品將在一起使用滥朱；系統(tǒng)提供一個產(chǎn)品類的庫根暑，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實現(xiàn)徙邻。

原型模式 (Prototype Pattern)

原型模式(Prototype Pattern)：使用原型實例指定創(chuàng)建對象的種類排嫌，并且通過拷貝這些原型創(chuàng)建新的對象。原型模式是一種對象創(chuàng)建型模式缰犁。

• 原型模式包含三個角色：抽象原型類是聲明克隆方法的接口淳地，是所有具體原型類的公共父類怖糊，可以是抽象類也可以是接口，甚至還可以是具體實現(xiàn)類颇象；具體原型類實現(xiàn)在抽象原型類中聲明的克隆方法蓬抄，在克隆方法中返回自己的一個克隆對象；客戶類讓一個原型對象克隆自身從而創(chuàng)建一個新的對象夯到，在客戶類中只需要直接實例化或通過工廠方法等方式創(chuàng)建一個原型對象嚷缭，再通過調(diào)用該對象的克隆方法即可得到多個相同的對象。
• 由于客戶類針對抽象原型類編程耍贾，因此用戶可以根據(jù)需要選擇具體原型類阅爽，系統(tǒng)具有較好的可擴展性，增加或更換具體原型類都很方便荐开。
• 原型模式的主要優(yōu)點是簡化復(fù)雜對象的創(chuàng)建過程付翁，擴展性較好，還可以使用深克隆的方式保存對象狀態(tài)晃听，在需要的時候使用可輔助實現(xiàn)撤銷操作百侧。主要缺點是需要為每一個類配備一個克隆方法，而且該克隆方法位于一個類的內(nèi)部能扒，當(dāng)對已有的類進行改造時佣渴，需要修改源代碼，違背了 “ 開閉原則 ”初斑；在實現(xiàn)深克隆時需要編寫較為復(fù)雜的代碼辛润。
• 原型模式的適用情況包括：創(chuàng)建新對象成本較大，新的對象可以通過原型模式對已有對象進行復(fù)制來獲得见秤；如果系統(tǒng)要保存對象的狀態(tài)砂竖；需要避免使用分層次的工廠類來創(chuàng)建分層次的對象，并且類的實例對象只有一個或很少的幾個組合狀態(tài)鹃答。

建造者模式 (Builder Pattern)

建造者模式(Builder Pattern)：將一個復(fù)雜對象的構(gòu)建與它的表示分離乎澄，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。建造者模式是一種對象創(chuàng)建型模式测摔。

• 建造者模式將一個復(fù)雜對象的構(gòu)建與它的表示分離置济，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。建造者模式是一步一步創(chuàng)建一個復(fù)雜的對象避咆，它允許用戶只通過指定復(fù)雜對象的類型和內(nèi)容就可以構(gòu)建它們舟肉，用戶不需要知道內(nèi)部的具體構(gòu)建細節(jié)。建造者模式屬于對象創(chuàng)建型模式查库。
• 建造者模式包含如下四個角色：抽象建造者為創(chuàng)建一個產(chǎn)品對象的各個部件指定抽象接口路媚；具體建造者實現(xiàn)了抽象建造者接口，實現(xiàn)各個部件的構(gòu)造和裝配方法樊销，定義并明確它所創(chuàng)建的復(fù)雜對象整慎，也可以提供一個方法返回創(chuàng)建好的復(fù)雜產(chǎn)品對象脏款；產(chǎn)品角色是被構(gòu)建的復(fù)雜對象，包含多個組成部件裤园；指揮者負責(zé)安排復(fù)雜對象的建造次序撤师，指揮者與抽象建造者之間存在關(guān)聯(lián)關(guān)系，可以在其 construct() 建造方法中調(diào)用建造者對象的部件構(gòu)造與裝配方法拧揽，完成復(fù)雜對象的建造剃盾。
• 在建造者模式的結(jié)構(gòu)中引入了一個指揮者類，該類的作用主要有兩個：一方面它隔離了客戶與生產(chǎn)過程淤袜；另一方面它負責(zé)控制產(chǎn)品的生成過程痒谴。指揮者針對抽象建造者編程，客戶端只需要知道具體建造者的類型铡羡，即可通過指揮者類調(diào)用建造者的相關(guān)方法积蔚，返回一個完整的產(chǎn)品對象。
• 建造者模式的主要優(yōu)點在于客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié)烦周，將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過程解耦尽爆，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象，每一個具體建造者都相對獨立读慎，而與其他的具體建造者無關(guān)漱贱，因此可以很方便地替換具體建造者或增加新的具體建造者，符合“開閉原則”贪壳，還可以更加精細地控制產(chǎn)品的創(chuàng)建過程饱亿；其主要缺點在于由于建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點，其組成部分相似闰靴，因此其使用范圍受到一定的限制，如果產(chǎn)品的內(nèi)部變化復(fù)雜钻注，可能會導(dǎo)致需要定義很多具體建造者類來實現(xiàn)這種變化蚂且，導(dǎo)致系統(tǒng)變得很龐大。
• 建造者模式適用情況包括：需要生成的產(chǎn)品對象有復(fù)雜的內(nèi)部結(jié)構(gòu)幅恋，這些產(chǎn)品對象通常包含多個成員屬性杏死；需要生成的產(chǎn)品對象的屬性相互依賴，需要指定其生成順序捆交；對象的創(chuàng)建過程獨立于創(chuàng)建該對象的類淑翼；隔離復(fù)雜對象的創(chuàng)建和使用，并使得相同的創(chuàng)建過程可以創(chuàng)建不同類型的產(chǎn)品品追。

2. 7 個結(jié)構(gòu)型模式

適配器模式 (Adapter Pattern)

適配器模式(Adapter Pattern)：將一個接口轉(zhuǎn)換成客戶希望的另一個接口玄括，使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)肉瓦。適配器模式既可以作為類結(jié)構(gòu)型模式遭京，也可以作為對象結(jié)構(gòu)型模式胃惜。

• 結(jié)構(gòu)型模式描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)。
• 適配器模式包含四個角色：目標(biāo)抽象類定義客戶要用的特定領(lǐng)域的接口哪雕；適配器類可以調(diào)用另一個接口船殉，作為一個轉(zhuǎn)換器，對適配者和抽象目標(biāo)類進行適配斯嚎，它是適配器模式的核心利虫；適配者類是被適配的角色，它定義了一個已經(jīng)存在的接口堡僻，這個接口需要適配糠惫；在客戶類中針對目標(biāo)抽象類進行編程，調(diào)用在目標(biāo)抽象類中定義的業(yè)務(wù)方法苦始。
• 在類適配器模式中寞钥，適配器類實現(xiàn)了目標(biāo)抽象類接口并繼承了適配者類，并在目標(biāo)抽象類的實現(xiàn)方法中調(diào)用所繼承的適配者類的方法陌选；在對象適配器模式中理郑，適配器類繼承了目標(biāo)抽象類并定義了一個適配者類的對象實例，在所繼承的目標(biāo)抽象類方法中調(diào)用適配者類的相應(yīng)業(yè)務(wù)方法咨油。
• 適配器模式的主要優(yōu)點是將目標(biāo)類和適配者類解耦您炉，增加了類的透明性和復(fù)用性，同時系統(tǒng)的靈活性和擴展性都非常好役电，更換適配器或者增加新的適配器都非常方便赚爵，符合“開閉原則”；類適配器模式的缺點是適配器類在很多編程語言中不能同時適配多個適配者類法瑟，對象適配器模式的缺點是很難置換適配者類的方法冀膝。
• 適配器模式適用情況包括：系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要霎挟；想要建立一個可以重復(fù)使用的類窝剖，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類一起工作。

橋接模式 (Bridge Pattern)

橋接模式(Bridge Pattern)：將抽象部分與它的實現(xiàn)部分分離酥夭，使它們都可以獨立地變化赐纱。它是一種對象結(jié)構(gòu)型模式，又稱為柄體(Handle and Body)模式或接口(Interface)模式熬北。

• 橋接模式包含如下四個角色：抽象類中定義了一個實現(xiàn)類接口類型的對象并可以維護該對象疙描；擴充抽象類擴充由抽象類定義的接口，它實現(xiàn)了在抽象類中定義的抽象業(yè)務(wù)方法讶隐，在擴充抽象類中可以調(diào)用在實現(xiàn)類接口中定義的業(yè)務(wù)方法起胰；實現(xiàn)類接口定義了實現(xiàn)類的接口，實現(xiàn)類接口僅提供基本操作整份，而抽象類定義的接口可能會做更多更復(fù)雜的操作待错；具體實現(xiàn)類實現(xiàn)了實現(xiàn)類接口并且具體實現(xiàn)它籽孙，在不同的具體實現(xiàn)類中提供基本操作的不同實現(xiàn)，在程序運行時火俄，具體實現(xiàn)類對象將替換其父類對象犯建，提供給客戶端具體的業(yè)務(wù)操作方法。
• 在橋接模式中瓜客，抽象化(Abstraction)與實現(xiàn)化(Implementation)脫耦适瓦，它們可以沿著各自的維度獨立變化。
• 橋接模式的主要優(yōu)點是分離抽象接口及其實現(xiàn)部分谱仪，是比多繼承方案更好的解決方法玻熙，橋接模式還提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度疯攒，都不需要修改原有系統(tǒng)嗦随，實現(xiàn)細節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細節(jié)敬尺；其主要缺點是增加系統(tǒng)的理解與設(shè)計難度枚尼，且識別出系統(tǒng)中兩個獨立變化的維度并不是一件容易的事情。
• 橋接模式適用情況包括：需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性砂吞，避免在兩個層次之間建立靜態(tài)的繼承聯(lián)系署恍；抽象化角色和實現(xiàn)化角色可以以繼承的方式獨立擴展而互不影響；一個類存在兩個獨立變化的維度蜻直，且這兩個維度都需要進行擴展盯质；設(shè)計要求需要獨立管理抽象化角色和具體化角色；不希望使用繼承或因為多層次繼承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)概而。

組合模式 (Composite Pattern)

組合模式(Composite Pattern)：組合多個對象形成樹形結(jié)構(gòu)以表示具有“整體—部分”關(guān)系的層次結(jié)構(gòu)呼巷。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性，組合模式又可以稱為“整體—部分”(Part-Whole)模式赎瑰，它是一種對象結(jié)構(gòu)型模式朵逝。

• 組合模式包含三個角色：抽象構(gòu)件可以是接口或抽象類，為葉子構(gòu)件和容器構(gòu)件對象聲明接口乡范，在該角色中可以包含所有子類共有行為的聲明和實現(xiàn)；葉子構(gòu)件表示葉子節(jié)點對象啤咽，葉子節(jié)點沒有子節(jié)點晋辆，它實現(xiàn)了在抽象構(gòu)件中定義的行為；容器構(gòu)件表示容器節(jié)點對象宇整，容器節(jié)點包含子節(jié)點瓶佳，其子節(jié)點可以是葉子節(jié)點，也可以是容器節(jié)點鳞青，它提供一個集合用于存儲子節(jié)點霸饲，實現(xiàn)了在抽象構(gòu)件中定義的行為为朋，包括那些訪問及管理子構(gòu)件的方法，在其業(yè)務(wù)方法中可以遞歸調(diào)用其子節(jié)點的業(yè)務(wù)方法厚脉。
• 組合模式的關(guān)鍵是定義了一個抽象構(gòu)件類习寸，它既可以代表葉子，又可以代表容器傻工，而客戶端針對該抽象構(gòu)件類進行編程霞溪，無須知道它到底表示的是葉子還是容器，可以對其進行統(tǒng)一處理中捆。
• 組合模式使用面向?qū)ο蟮乃枷雭韺崿F(xiàn)樹形結(jié)構(gòu)的構(gòu)建與處理鸯匹，描述了如何將容器對象和葉子對象進行遞歸組合，實現(xiàn)簡單损同，靈活性好稽寒。
• 組合模式的主要優(yōu)點是清楚地定義分層次的復(fù)雜對象庙曙，方便對整個層次結(jié)構(gòu)進行控制；客戶端可以一致地使用一個組合結(jié)構(gòu)或其中單個對象染厅，簡化了客戶端代碼；增加新的容器構(gòu)件和葉子構(gòu)件都很方便脓杉，無須對現(xiàn)有類庫進行任何修改糟秘，符合“開閉原則”。其主要缺點是在增加新構(gòu)件時很難對容器中的構(gòu)件類型進行限制球散。
• 組合模式適用情況包括：在具有整體和部分的層次結(jié)構(gòu)中尿赚，希望通過一種方式忽略整體與部分的差異，客戶端可以一致地對待它們蕉堰；在一個使用面向?qū)ο笳Z言開發(fā)的系統(tǒng)中需要處理一個樹形結(jié)構(gòu)凌净；在一個系統(tǒng)中能夠分離出葉子對象和容器對象，而且它們的類型不固定屋讶，需要增加一些新的類型冰寻。

裝飾模式 (Decorator Pattern)

裝飾模式(Decorator Pattern)：動態(tài)地給一個對象增加一些額外的職責(zé)，就增加對象功能來說皿渗，裝飾模式比生成子類實現(xiàn)更為靈活斩芭。裝飾模式是一種對象結(jié)構(gòu)型模式。

• 裝飾模式包含四個角色：抽象構(gòu)件定義了對象的接口乐疆，可以給這些對 象動態(tài)增加職責(zé)（方法）划乖；具體構(gòu)件定義了具體的構(gòu)件對象，實現(xiàn)了 在抽象構(gòu)件中聲明的方法挤土，裝飾器可以給它增加額外的職責(zé)（方法）琴庵； 抽象裝飾類是抽象構(gòu)件類的子類，用于給具體構(gòu)件增加職責(zé)，但是具體職責(zé)在其子類中實現(xiàn)迷殿；具體裝飾類是抽象裝飾類的子類儿礼，負責(zé)向構(gòu)件添加新的職責(zé)。
• 使用裝飾模式來實現(xiàn)擴展比繼承更加靈活庆寺，它以對客戶透明的方式動態(tài)地給一個對象附加更多的責(zé)任蚊夫。裝飾模式可以在不需要創(chuàng)造更多子類的情況下，將對象的功能加以擴展止邮。
• 裝飾模式的主要優(yōu)點在于可以提供比繼承更多的靈活性这橙，可以通過一種動態(tài)的方式來擴展一個對象的功能，并通過使用不同的具體裝飾類以及這些裝飾類的排列組合导披，可以創(chuàng)造出很多不同行為的組合屈扎，而且具體構(gòu)件類與具體裝飾類可以獨立變化，用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類撩匕；其主要缺點在于使用裝飾模式進行系統(tǒng)設(shè)計時將產(chǎn)生很多小對象鹰晨，而且裝飾模式比繼承更加易于出錯，排錯也很困難止毕，對于多次裝飾的對象模蜡，調(diào)試時尋找錯誤可能需要逐級排查，較為煩瑣扁凛。
• 裝飾模式適用情況包括：在不影響其他對象的情況下忍疾，以動態(tài)、透明的方式給單個對象添加職責(zé)谨朝；需要動態(tài)地給一個對象增加功能卤妒，這些功能也可以動態(tài)地被撤銷；當(dāng)不能采用繼承的方式對系統(tǒng)進行擴充或者采用繼承不利于系統(tǒng)擴展和維護時字币。
• 裝飾模式可分為透明裝飾模式和半透明裝飾模式：在透明裝飾模式中则披，要求客戶端完全針對抽象編程，裝飾模式的透明性要求客戶端程序不應(yīng)該聲明具體構(gòu)件類型和具體裝飾類型洗出，而應(yīng)該全部聲明為抽象構(gòu)件類型士复；半透明裝飾模式允許用戶在客戶端聲明具體裝飾者類型的對象，調(diào)用在具體裝飾者中新增的方法翩活。

外觀模式 (Facade Pattern)

外觀模式(Facade Pattern)：外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的外觀對象進行阱洪，為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口菠镇，這個接口使得這一子系統(tǒng)更加容易使用澄峰。外觀模式又稱為門面模式，它是一種對象結(jié)構(gòu)型模式辟犀。

• 外觀模式包含兩個角色：外觀角色是在客戶端直接調(diào)用的角色，在外觀角色中可以知道相關(guān)的(一個或者多個)子系統(tǒng)的功能和責(zé)任，它將所有從客戶端發(fā)來的請求委派到相應(yīng)的子系統(tǒng)去堂竟，傳遞給相應(yīng)的子系統(tǒng)對象處理魂毁；在軟件系統(tǒng)中可以同時有一個或者多個子系統(tǒng)角色，每一個子系統(tǒng)可以不是一個單獨的類出嘹，而是一個類的集合席楚，它實現(xiàn)子系統(tǒng)的功能。
• 外觀模式要求一個子系統(tǒng)的外部與其內(nèi)部的通信通過一個統(tǒng)一的外觀對象進行税稼，外觀類將客戶端與子系統(tǒng)的內(nèi)部復(fù)雜性分隔開烦秩，使得客戶端只需要與外觀對象打交道，而不需要與子系統(tǒng)內(nèi)部的很多對象打交道郎仆。
• 外觀模式主要優(yōu)點在于對客戶屏蔽子系統(tǒng)組件只祠，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易，它實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系扰肌，并降低了大型軟件系統(tǒng)中的編譯依賴性抛寝，簡化了系統(tǒng)在不同平臺之間的移植過程；其缺點在于不能很好地限制客戶使用子系統(tǒng)類曙旭，而且在不引入抽象外觀類的情況下盗舰，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”桂躏。
• 外觀模式適用情況包括：要為一個復(fù)雜子系統(tǒng)提供一個簡單接口钻趋；客戶程序與多個子系統(tǒng)之間存在很大的依賴性；在層次化結(jié)構(gòu)中剂习，需要定義系統(tǒng)中每一層的入口蛮位，使得層與層之間不直接產(chǎn)生聯(lián)系。

享元模式 (Flyweight Pattern)

享元模式(Flyweight Pattern)：運用共享技術(shù)有效地支持大量細粒度對象的復(fù)用进倍。系統(tǒng)只使用少量的對象土至，而這些對象都很相似，狀態(tài)變化很小猾昆，可以實現(xiàn)對象的多次復(fù)用陶因。由于享元模式要求能夠共享的對象必須是細粒度對象，因此它又稱為輕量級模式垂蜗，它是一種對象結(jié)構(gòu)型模式楷扬。

• 享元模式包含四個角色：抽象享元類聲明一個接口，通過它可以接受并作用于外部狀態(tài)贴见；具體享元類實現(xiàn)了抽象享元接口烘苹，其實例稱為享元對象；非共享具體享元是不能被共享的抽象享元類的子類片部；享元工廠類用于創(chuàng)建并管理享元對象镣衡，它針對抽象享元類編程，將各種類型的具體享元對象存儲在一個享元池中。
• 享元模式以共享的方式高效地支持大量的細粒度對象廊鸥，享元對象能做到共享的關(guān)鍵是區(qū)分內(nèi)部狀態(tài)和外部狀態(tài)望浩。其中內(nèi)部狀態(tài)是存儲在享元對象內(nèi)部并且不會隨環(huán)境改變而改變的狀態(tài)，因此內(nèi)部狀態(tài)可以共享惰说；外部狀態(tài)是隨環(huán)境改變而改變的磨德、不可以共享的狀態(tài)。
• 享元模式主要優(yōu)點在于它可以極大減少內(nèi)存中對象的數(shù)量吆视，使得相同對象或相似對象在內(nèi)存中只保存一份典挑；其缺點是使得系統(tǒng)更加復(fù)雜，并且需要將享元對象的狀態(tài)外部化啦吧，而讀取外部狀態(tài)使得運行時間變長您觉。
• 享元模式適用情況包括：一個系統(tǒng)有大量相同或者相似的對象，由于這類對象的大量使用丰滑，造成內(nèi)存的大量耗費顾犹；對象的大部分狀態(tài)都可以外部化，可以將這些外部狀態(tài)傳入對象中褒墨；多次重復(fù)使用享元對象炫刷。

代理模式 (Proxy Pattern)

代理模式(Proxy Pattern)：給某一個對象提供一個代理，并由代理對象控制對原對象的引用郁妈。代理模式的英 文叫做 Proxy 或 Surrogate 浑玛，它是一種對象結(jié)構(gòu)型模式。

• 代理模式包含三個角色：抽象主題角色聲明了真實主題和代理主題的共同接口噩咪；代理主題角色內(nèi)部包含對真實主題的引用顾彰，從而可以在任何時候操作真實主題對象；真實主題角色定義了代理角色所代表的真實對象胃碾，在真實主題角色中實現(xiàn)了真實的業(yè)務(wù)操作涨享，客戶端可以通過代理主題角色間接調(diào)用真實主題角色中定義的方法。
• 代理模式的優(yōu)點在于能夠協(xié)調(diào)調(diào)用者和被調(diào)用者仆百，在一定程度上降低了系統(tǒng)的耦合度厕隧；其缺點在于由于在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢俄周，并且實現(xiàn)代理模式需要額外的工作吁讨，有些代理模式的實現(xiàn)非常復(fù)雜。
• 遠程代理為一個位于不同的地址空間的對象提供一個本地的代表對象峦朗，它使得客戶端可以訪問在遠程機器上的對象建丧，遠程機器可能具有更好的計算性能與處理速度，可以快速響應(yīng)并處理客戶端請求波势。
• 如果需要創(chuàng)建一個資源消耗較大的對象翎朱，先創(chuàng)建一個消耗相對較小的對象來表示橄维，真實對象只在需要時才會被真正創(chuàng)建，這個小對象稱為虛擬代理闭翩。虛擬代理通過使用一個小對象來代表一個大對象挣郭，可以減少系統(tǒng)資源的消耗，對系統(tǒng)進行優(yōu)化并提高運行速度疗韵。
• 保護代理可以控制對一個對象的訪問，可以給不同的用戶提供不同級別的使用權(quán)限侄非。

3. 11 個行為型模式

職責(zé)鏈模式 (Chain of Responsibility Pattern)

職責(zé)鏈模式(Chain of Responsibility Pattern)：避免請求發(fā)送者與接收者耦合在一起蕉汪，讓多個對象都有可能接收請求，將這些對象連接成一條鏈逞怨，并且沿著這條鏈傳遞請求者疤，直到有對象處理它為止。職責(zé)鏈模式是一種對象行為型模式叠赦。

• 職責(zé)鏈模式包含兩個角色：抽象處理者定義了一個處理請求的接口驹马，一般設(shè)計為抽象類，由于不同的具體處理者處理請求的方式不同除秀，因此在其中定義了抽象請求處理方法糯累；具體處理者是抽象處理者的子類，可以處理用戶請求册踩，在具體處理者類中實現(xiàn)了抽象處理者中定義的抽象請求處理方法泳姐，在處理請求之前需要進行判斷，看是否有相應(yīng)的處理權(quán)限暂吉，如果可以處理請求就處理它胖秒，否則將請求轉(zhuǎn)發(fā)給后繼者。
• 在職責(zé)鏈模式里慕的，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈阎肝。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求肮街。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求风题，這使得系統(tǒng)可以在不影響客戶端的情況下動態(tài)地重新組織鏈和分配責(zé)任。
• 職責(zé)鏈模式的主要優(yōu)點是使得一個對象無須知道是其他哪一個對象處理其請求低散，對象僅需知道該請求會被處理即可俯邓，降低了系統(tǒng)的耦合度，簡化了對象的相互連接熔号，可以動態(tài)地重新組織鏈和分配責(zé)任稽鞭；主要缺點是一個請求也可能因職責(zé)鏈沒有被正確配置而得不到處理，對于比較長的職責(zé)鏈引镊，系統(tǒng)性能將受到一定影響朦蕴，而且在進行代碼調(diào)試時不太方便篮条，還可能陷入死循環(huán)。
• 職責(zé)鏈模式的適用情況包括：有多個對象可以處理同一個請求吩抓，具體哪個對象處理該請求待運行時刻再確定涉茧；可動態(tài)指定一組對象處理請求，客戶端可以動態(tài)創(chuàng)建職責(zé)鏈來處理請求疹娶，還可以改變鏈中處理者之間的先后次序伴栓；在不明確指定接收者的情況下，向多個對象中的一個提交一個請求雨饺。

命令模式 (Command Pattern)

命令模式(Command Pattern)：將一個請求封裝為一個對象钳垮，從而使我們可用不同的請求對客戶進行參數(shù)化；對請求排隊或者記錄請求日志额港，以及支持可撤銷的操作饺窿。命令模式是一種對象行為型模式，其別名為動作 (Action) 模式或事務(wù) (Transaction) 模式移斩。

• 命令模式包含四個角色：抽象命令類中聲明了用于執(zhí)行請求的 execute() 等方法肚医，通過這些方法可以調(diào)用請求接收者的相關(guān)操作；具體命令類是抽象命令類的子類向瓷，實現(xiàn)了在抽象命令類中聲明的方法肠套，它對應(yīng)具體的接收者對象，將接收者對象的動作綁定其中风罩；調(diào)用者即請求的發(fā)送者糠排，又稱為請求者，它通過命令對象來執(zhí)行請求超升；接收者執(zhí)行與請求相關(guān)的操作入宦，它具體實現(xiàn)對請求的業(yè)務(wù)處理。
• 命令模式的本質(zhì)是對命令進行封裝室琢，將發(fā)出命令的責(zé)任和執(zhí)行命令的責(zé)任分割開乾闰。命令模式使請求本身成為一個對象，這個對象和其他對象一樣可以被存儲和傳遞盈滴。
• 命令模式的主要優(yōu)點在于降低系統(tǒng)的耦合度涯肩，增加新的命令很方便，而且可以比較容易地設(shè)計一個命令隊列和宏命令巢钓，并方便地實現(xiàn)對請求的撤銷和恢復(fù)病苗；其主要缺點在于可能會導(dǎo)致某些系統(tǒng)有過多的具體命令類。
• 命令模式適用情況包括：需要將請求調(diào)用者和請求接收者解耦症汹，使得調(diào)用者和接收者不直接交互硫朦；需要在不同的時間指定請求、將請求排隊和執(zhí)行請求背镇；需要支持命令的撤銷操作和恢復(fù)操作咬展，需要將一組操作組合在一起泽裳，即支持宏命令。

解釋器模式 (Interpreter Pattern)

解釋器模式(Interpreter Pattern)：定義一個語言的文法破婆，并且建立一個解釋器來解釋該語言中的句子涮总，這里的 “語言” 是指使用規(guī)定格式和語法的代碼。解釋器模式是一種類行為型模式祷舀。

• 解釋器模式包含四個角色：抽象表達式聲明了抽象的解釋操作瀑梗，它是所有終結(jié)符表達式和非終結(jié)符表達式的公共父類；終結(jié)符表達式是抽象表達式的子類裳扯，它實現(xiàn)了與文法中的終結(jié)符相關(guān)聯(lián)的解釋操作夺克，在句子中的每一個終結(jié)符都是該類的一個實例；非終結(jié)符表達式也是抽象表達式的子類嚎朽，它實現(xiàn)了文法中非終結(jié)符的解釋操作，由于在非終結(jié)符表達式中可以包含終結(jié)符表達式柬帕，也可以繼續(xù)包含非終結(jié)符表達式哟忍，因此其解釋操作一般通過遞歸的方式來完成；環(huán)境類又稱為上下文類陷寝，它用于存儲解釋器之外的一些全局信息锅很，通常它臨時存儲了需要解釋的語句。
• 解釋器模式為自定義語言的設(shè)計和實現(xiàn)提供了一種解決方案凤跑，它用于定義一組文法規(guī)則并通過這組文法規(guī)則來解釋語言中的句子爆安。雖然解釋器模式的使用頻率不是特別高，但是它在正則表達式仔引、XML文檔解釋等領(lǐng)域還是得到了廣泛使用扔仓。
• 解釋器模式的主要優(yōu)點是易于改變和擴展文法；主要缺點是對于復(fù)雜文法難以維護咖耘，執(zhí)行效率低翘簇，由于使用了大量的循環(huán)和遞歸調(diào)用，因此在解釋較為復(fù)雜的句子時其速度很慢儿倒，而且代碼的調(diào)試過程也比較麻煩版保。
• 解釋器模式適用情景包括：可以將一個需要解釋執(zhí)行的語言中的句子表示為一個抽象語法樹；一些重復(fù)出現(xiàn)的問題可以用一種簡單的語言來進行表達夫否；一個語言的文法較為簡單彻犁。

迭代器模式 (Iterator Pattern)

迭代器模式(Iterator Pattern)：提供一種方法來訪問聚合對象，而不用暴露這個對象的內(nèi)部表示凰慈，其別名為游標(biāo)(Cursor)汞幢。迭代器模式是一種對象行為型模式。

• 迭代器模式包含四個角色：抽象迭代器定義了訪問和遍歷元素的接口溉瓶，聲明了用于遍歷數(shù)據(jù)元素的方法急鳄；具體迭代器實現(xiàn)了抽象迭代器接口谤民，完成對聚合對象的遍歷，同時在具體迭代器中通過游標(biāo)來記錄在聚合對象中所處的當(dāng)前位置疾宏；抽象聚合類用于存儲和管理元素對象张足；具體聚合類實現(xiàn)了在抽象聚合類中聲明的 createIterator() 方法，該方法返回一個與該具體聚合類對應(yīng)的具體迭代器 ConcreteIterator 實例坎藐。
• 需要注意的是抽象迭代器接口的設(shè)計非常重要为牍，一方面需要充分滿足各種遍歷操作的要求，盡量為各種遍歷方法都提供聲明岩馍，另一方面又不能包含太多方法碉咆，接口中方法太多將給子類的實現(xiàn)帶來麻煩。因此蛀恩，可以考慮使用抽象類來設(shè)計抽象迭代器疫铜，在抽象類中為每一個方法提供一個空的默認實現(xiàn)。
• 迭代器模式是一種使用頻率非常高的設(shè)計模式双谆，通過引入迭代器可以將數(shù)據(jù)的遍歷功能從聚合對象中分離出來壳咕，聚合對象只負責(zé)存儲數(shù)據(jù)，而遍歷數(shù)據(jù)由迭代器來完成顽馋。
• 迭代器模式的主要優(yōu)點是支持以不同的方式遍歷一個聚合對象谓厘，簡化了聚合類；主要缺點是由于將存儲數(shù)據(jù)和遍歷數(shù)據(jù)的職責(zé)分離寸谜，增加新的聚合類需要對應(yīng)增加新的迭代器類竟稳，類的個數(shù)成對增加，這在一定程度上增加了系統(tǒng)的復(fù)雜性熊痴，而且抽象迭代器的設(shè)計難度較大他爸，需要充分考慮到系統(tǒng)將來的擴展。
• 迭代器模式適用情景包括：訪問一個聚合對象的內(nèi)容而無須暴露它的內(nèi)部表示愁拭；需要為一個聚合對象提供多種遍歷方式讲逛；為遍歷不同的聚合結(jié)構(gòu)提供一個統(tǒng)一的接口，在該接口的實現(xiàn)類中為不同的聚合結(jié)構(gòu)提供不同的遍歷方式岭埠，而客戶端可以一致性地操作該接口盏混。

中介者模式 (Mediator Pattern)

中介者模式(Mediator Pattern)：用一個中介對象（中介者）來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用惜论，從而使其耦合松散许赃，而且可以獨立地改變它們之間的交互。中介者模式又稱為調(diào)停者模式馆类，它是一種對象行為型模式混聊。

• 中介者模式包含四個角色：抽象中介者用于定義一個接口，該接口用于與各同事對象之間的通信乾巧；具體中介者是抽象中介者的子類句喜，通過協(xié)調(diào)各個同事對象來實現(xiàn)協(xié)作行為预愤，了解并維護它的各個同事對象的引用；抽象同事類定義各同事的公有方法咳胃；具體同事類是抽象同事類的子類植康，每一個同事對象都引用一個中介者對象；每一個同事對象在需要和其他同事對象通信時展懈，先與中介者通信销睁，通過中介者來間接完成與其他同事類的通信；在具體同事類中實現(xiàn)了在抽象同事類中定義的方法存崖。
• 通過引入中介者對象冻记，可以將系統(tǒng)的網(wǎng)狀結(jié)構(gòu)變成以中介者為中心的星形結(jié)構(gòu)，中介者承擔(dān)了中轉(zhuǎn)作用和協(xié)調(diào)作用来惧。中介者類是中介者模式的核心冗栗，它對整個系統(tǒng)進行控制和協(xié)調(diào)，簡化了對象之間的交互供搀，還可以對對象間的交互進行進一步的控制贞瞒。
• 中介者模式的主要優(yōu)點在于簡化了對象之間的交互，將各同事解耦趁曼，還可以減少子類生成，對于復(fù)雜的對象之間的交互棕洋，通過引入中介者挡闰，可以簡化各同事類的設(shè)計和實現(xiàn)；中介者模式主要缺點在于具體中介者類中包含了同事之間的交互細節(jié)掰盘，可能會導(dǎo)致具體中介者類非常復(fù)雜摄悯，使得系統(tǒng)難以維護。
• 中介者模式適用情況包括：系統(tǒng)中對象之間存在復(fù)雜的引用關(guān)系愧捕，產(chǎn)生的相互依賴關(guān)系結(jié)構(gòu)混亂且難以理解奢驯；一個對象由于引用了其他很多對象并且直接和這些對象通信，導(dǎo)致難以復(fù)用該對象次绘；想通過一個中間類來封裝多個類中的行為瘪阁，而又不想生成太多的子類。

備忘錄模式 (Memento Pattern)

備忘錄模式(Memento Pattern)：在不破壞封裝的前提下邮偎，捕獲一個對象的內(nèi)部狀態(tài)管跺，并在該對象之外保存這個狀態(tài)，這樣可以在以后將對象恢復(fù)到原先保存的狀態(tài)禾进。它是一種對象行為型模式豁跑，其別名為Token。

• 備忘錄模式包含三個角色：原發(fā)器用于創(chuàng)建一個備忘錄泻云；備忘錄存儲原發(fā)器的內(nèi)部狀態(tài)艇拍，根據(jù)原發(fā)器來決定保存哪些內(nèi)部狀態(tài)狐蜕；負責(zé)人又稱為管理者，它負責(zé)保存?zhèn)渫浶断Γ遣荒軐渫浀膬?nèi)容進行操作或檢查层释。
• 在設(shè)計備忘錄類時需要考慮其封裝性，除了原發(fā)器類娇哆，不允許其他類來調(diào)用備忘錄類的構(gòu)造函數(shù)與相關(guān)方法湃累，如果不考慮封裝性，允許其他類調(diào)用setState()等方法碍讨，將導(dǎo)致在備忘錄中保存的歷史狀態(tài)發(fā)生改變治力，通過撤銷操作所恢復(fù)的狀態(tài)就不再是真實的歷史狀態(tài)，備忘錄模式也就失去了本身的意義勃黍。
• 備忘錄模式的主要優(yōu)點是提供了一種狀態(tài)恢復(fù)的實現(xiàn)機制宵统，使得用戶可以方便地回到一個特定的歷史步驟；主要缺點是資源消耗過大覆获，如果需要保存的原發(fā)器類的成員變量太多马澈，就不可避免需要占用大量的存儲空間，每保存一次對象的狀態(tài)都需要消耗一定的系統(tǒng)資源弄息。
• 備忘錄模式適用情景包括：保存一個對象在某一個時刻的全部狀態(tài)或部分狀態(tài)痊班，這樣以后需要時它能夠恢復(fù)到先前的狀態(tài)，實現(xiàn)撤銷操作摹量；防止外界對象破壞一個對象歷史狀態(tài)的封裝性涤伐，避免將對象歷史狀態(tài)的實現(xiàn)細節(jié)暴露給外界對象。

觀察者模式 (Observer Pattern)

觀察者模式(Observer Pattern)：定義對象之間的一種一對多依賴關(guān)系缨称，使得每當(dāng)一個對象狀態(tài)發(fā)生改變時凝果，其相關(guān)依賴對象皆得到通知并被自動更新。觀察者模式的別名包括發(fā)布-訂閱（Publish/Subscribe）模式睦尽、模型-視圖（Model/View）模式器净、源-監(jiān)聽器（Source/Listener）模式或從屬者（Dependents）模式。觀察者模式是一種對象行為型模式当凡。

• 觀察者模式包含四個角色：目標(biāo)又稱為主題山害，它是指被觀察的對象；具體目標(biāo)是目標(biāo)類的子類沿量，通常它包含有經(jīng)常發(fā)生改變的數(shù)據(jù)粗恢，當(dāng)它的狀態(tài)發(fā)生改變時，向它的各個觀察者發(fā)出通知欧瘪；觀察者將對觀察目標(biāo)的改變做出反應(yīng)眷射；在具體觀察者中維護一個指向具體目標(biāo)對象的引用，它存儲具體觀察者的有關(guān)狀態(tài)，這些狀態(tài)需要和具體目標(biāo)的狀態(tài)保持一致妖碉。
• 觀察者模式定義了一種一對多的依賴關(guān)系涌庭，讓多個觀察者對象同時監(jiān)聽某一個目標(biāo)對象，當(dāng)這個目標(biāo)對象的狀態(tài)發(fā)生變化時欧宜，會通知所有觀察者對象坐榆，使它們能夠自動更新。
• 觀察者模式的主要優(yōu)點在于可以實現(xiàn)表示層和數(shù)據(jù)邏輯層的分離冗茸，并在觀察目標(biāo)和觀察者之間建立一個抽象的耦合席镀，支持廣播通信；其主要缺點在于如果一個觀察目標(biāo)對象有很多直接和間接的觀察者的話夏漱，將所有的觀察者都通知到會花費很多時間豪诲，而且如果在觀察者和觀察目標(biāo)之間有循環(huán)依賴的話，觀察目標(biāo)會觸發(fā)它們之間進行循環(huán)調(diào)用挂绰，可能導(dǎo)致系統(tǒng)崩潰屎篱。
• 觀察者模式適用情況包括：一個抽象模型有兩個方面，其中一個方面依賴于另一個方面葵蒂；一個對象的改變將導(dǎo)致其他一個或多個對象也發(fā)生改變交播，而不知道具體有多少對象將發(fā)生改變；一個對象必須通知其他對象践付，而并不知道這些對象是誰秦士；需要在系統(tǒng)中創(chuàng)建一個觸發(fā)鏈。

狀態(tài)模式 (State Pattern)

狀態(tài)模式(State Pattern)：允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為永高，對象看起來似乎修改了它的類伍宦。其別名為狀態(tài)對象(Objects for States)，狀態(tài)模式是一種對象行為型模式乏梁。

• 狀態(tài)模式包含三個角色：環(huán)境類又稱為上下文類，它是擁有狀態(tài)的對象关贵，在環(huán)境類中維護一個抽象狀態(tài)類 State 的實例遇骑，這個實例定義當(dāng)前狀態(tài)，在具體實現(xiàn)時揖曾，它是一個 State 子類的對象落萎，可以定義初始狀態(tài)；抽象狀態(tài)類用于定義一個接口以封裝與環(huán)境類的一個特定狀態(tài)相關(guān)的行為炭剪；具體狀態(tài)類是抽象狀態(tài)類的子類练链，每一個子類實現(xiàn)一個與環(huán)境類的一個狀態(tài)相關(guān)的行為，每一個具體狀態(tài)類對應(yīng)環(huán)境的一個具體狀態(tài)奴拦，不同的具體狀態(tài)類其行為有所不同媒鼓。
• 狀態(tài)模式描述了對象狀態(tài)的變化以及對象如何在每一種狀態(tài)下表現(xiàn)出不同的行為。
• 狀態(tài)模式的主要優(yōu)點在于封裝了轉(zhuǎn)換規(guī)則，并枚舉可能的狀態(tài)，它將所有與某個狀態(tài)有關(guān)的行為放到一個類中，并且可以方便地增加新的狀態(tài)锋边，只需要改變對象狀態(tài)即可改變對象的行為贫悄，還可以讓多個環(huán)境對象共享一個狀態(tài)對象，從而減少系統(tǒng)中對象的個數(shù)陨仅；其缺點在于使用狀態(tài)模式會增加系統(tǒng)類和對象的個數(shù)，且狀態(tài)模式的結(jié)構(gòu)與實現(xiàn)都較為復(fù)雜，如果使用不當(dāng)將導(dǎo)致程序結(jié)構(gòu)和代碼的混亂究流，對于可以切換狀態(tài)的狀態(tài)模式不滿足“開閉原則”的要求。
• 狀態(tài)模式適用情況包括：對象的行為依賴于它的狀態(tài)（屬性）并且可以根據(jù)它的狀態(tài)改變而改變它的相關(guān)行為动遭；代碼中包含大量與對象狀態(tài)有關(guān)的條件語句芬探，這些條件語句的出現(xiàn)，會導(dǎo)致代碼的可維護性和靈活性變差沽损，不能方便地增加和刪除狀態(tài)灯节，使客戶類與類庫之間的耦合增強。

策略模式 (Strategy Pattern)

策略模式(Strategy Pattern)：定義一系列算法類绵估，將每一個算法封裝起來炎疆，并讓它們可以相互替換，策略模式讓算法獨立于使用它的客戶而變化国裳，也稱為政策模式(Policy)形入。策略模式是一種對象行為型模式。

• 策略模式包含三個角色：環(huán)境類在解決某個問題時可以采用多種策略缝左，在環(huán)境類中維護一個對抽象策略類的引用實例亿遂；抽象策略類為所支持的算法聲明了抽象方法，是所有策略類的父類渺杉；具體策略類實現(xiàn)了在抽象策略類中定義的算法蛇数。
• 策略模式是對算法的封裝，它把算法的責(zé)任和算法本身分割開是越，委派給不同的對象管理耳舅。策略模式通常把一個系列的算法封裝到一系列的策略類里面，作為一個抽象策略類的子類倚评。
• 策略模式主要優(yōu)點在于對“開閉原則”的完美支持浦徊，在不修改原有系統(tǒng)的基礎(chǔ)上可以更換算法或者增加新的算法，它很好地管理算法族天梧，提高了代碼的復(fù)用性盔性，是一種替換繼承，避免多重條件轉(zhuǎn)移語句的實現(xiàn)方式呢岗；其缺點在于客戶端必須知道所有的策略類冕香，并理解其區(qū)別蛹尝，同時在一定程度上增加了系統(tǒng)中類的個數(shù)，可能會存在很多策略類暂筝。
• 策略模式適用情況包括：在一個系統(tǒng)里面有許多類箩言，它們之間的區(qū)別僅在于它們的行為，使用策略模式可以動態(tài)地讓一個對象在許多行為中選擇一種行為焕襟；一個系統(tǒng)需要動態(tài)地在幾種算法中選擇一種陨收；避免使用難以維護的多重條件選擇語句；希望在具體策略類中封裝算法和與相關(guān)的數(shù)據(jù)結(jié)構(gòu)鸵赖。

模板方法模式 (Template Method Pattern)

模板方法模式(Template Method Pattern)：定義一個操作中算法的框架务漩，而將一些步驟延遲到子類中。模板方法模式使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟它褪。模板方法模式是一種基于繼承的代碼復(fù)用技術(shù)饵骨，它是一種類行為型模式。

• 模板方法模式包含兩個角色：抽象類定義了一系列基本操作茫打，這些基本操作可以是具體的居触，也可以是抽象的，每一個基本操作對應(yīng)算法的一個步驟老赤，在其子類中可以重定義或?qū)崿F(xiàn)這些步驟轮洋；具體子類是抽象類的子類，用于實現(xiàn)在父類中聲明的抽象基本操作以完成子類特定算法的步驟抬旺，也可以覆蓋在父類中已經(jīng)實現(xiàn)的具體基本操作弊予。
• 在模板方法模式中，由于面向?qū)ο蟮亩鄳B(tài)性开财，子類對象在運行時將覆蓋父類對象汉柒，子類中定義的方法也將覆蓋父類中定義的方法，因此程序在運行時责鳍，具體子類的基本方法將覆蓋父類中定義的基本方法碾褂，子類的鉤子方法也將覆蓋父類的鉤子方法，從而可以通過在子類中實現(xiàn)的鉤子方法對父類方法的執(zhí)行進行約束历葛，實現(xiàn)子類對父類行為的反向控制正塌。
• 模板方法模式的主要優(yōu)點是在父類中形式化地定義一個算法，而由它的子類來實現(xiàn)細節(jié)的處理啃洋，在子類實現(xiàn)詳細的處理算法時并不會改變算法中步驟的執(zhí)行次序，將公共行為放在父類中屎鳍，而通過其子類來實現(xiàn)不同的行為宏娄，可實現(xiàn)一種反向控制結(jié)構(gòu)，通過子類覆蓋父類的鉤子方法來決定某一特定步驟是否需要執(zhí)行逮壁，更換和增加新的子類很方便孵坚，符合單一職責(zé)原則和開閉原則；其主要缺點是需要為每一個基本方法的不同實現(xiàn)提供一個子類，如果父類中可變的基本方法太多卖宠，將會導(dǎo)致類的個數(shù)增加巍杈，系統(tǒng)更加龐大，設(shè)計也更加抽象扛伍。
• 模板方法模式適用情景包括：對一些復(fù)雜的算法進行分割筷畦，將其算法中固定不變的部分設(shè)計為模板方法和父類具體方法，而一些可以改變的細節(jié)由其子類來實現(xiàn)刺洒；需要通過子類來決定父類算法中某個步驟是否執(zhí)行鳖宾，實現(xiàn)子類對父類的反向控制。

訪問者模式 (Visitor Pattern)

訪問者模式(Visitor Pattern)：提供一個作用于某對象結(jié)構(gòu)中的各元素的操作表示逆航，它使我們可以在不改變各元素的類的前提下定義作用于這些元素的新操作鼎文。訪問者模式是一種對象行為型模式。

• 訪問者模式包含五個角色：抽象訪問者為對象結(jié)構(gòu)中每一個具體元素類聲明一個訪問操作因俐；具體訪問者實現(xiàn)了每個由抽象訪問者聲明的操作拇惋；抽象元素一般是抽象類或者接口，它定義一個 accept() 方法抹剩，該方法通常以一個抽象訪問者作為參數(shù)撑帖；具體元素實現(xiàn)了 accept() 方法，在accept()方法中調(diào)用訪問者的訪問方法以便完成對一個元素的操作吧兔；對象結(jié)構(gòu)是一個元素的集合磷仰，它用于存放元素對象，并且提供了遍歷其內(nèi)部元素的方法境蔼。
• 訪問者模式中對象結(jié)構(gòu)存儲了不同類型的元素對象灶平，以供不同訪問者訪問。訪問者模式包括兩個層次結(jié)構(gòu)箍土，一個是訪問者層次結(jié)構(gòu)逢享，提供了抽象訪問者和具體訪問者，一個是元素層次結(jié)構(gòu)吴藻，提供了抽象元素和具體元素瞒爬。相同的訪問者可以以不同的方式訪問不同的元素，相同的元素可以接受不同訪問者以不同訪問方式訪問沟堡。在訪問者模式中侧但，增加新的訪問者無須修改原有系統(tǒng)，系統(tǒng)具有較好的可擴展性航罗。
• 訪問者模式的主要優(yōu)點是增加新的訪問操作很方便禀横，讓用戶能夠在不修改現(xiàn)有元素類層次結(jié)構(gòu)的情況下，定義作用于該層次結(jié)構(gòu)的操作粥血；其缺點是增加新的元素類很困難柏锄，破壞了封裝性酿箭。
• 訪問者模式適用情景包括：個對象結(jié)構(gòu)包含多個類型的對象，希望對這些對象實施一些依賴其具體類型的操作趾娃；需要對一個對象結(jié)構(gòu)中的對象進行很多不同的并且不相關(guān)的操作缭嫡，而需要避免讓這些操作 “污染” 這些對象的類，也不希望在增加新操作時修改這些類抬闷；對象結(jié)構(gòu)中對象對應(yīng)的類很少改變妇蛀，但經(jīng)常需要在此對象結(jié)構(gòu)上定義新的操作。

參考資料：
史上最全設(shè)計模式導(dǎo)學(xué)目錄（完整版）
設(shè)計模式 | 菜鳥教程
圖說設(shè)計模式