設(shè)計(jì)模式匯總

一、基礎(chǔ)知識(shí)

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

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

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

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

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

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

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

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

二、24 種設(shè)計(jì)模式簡(jiǎn)介

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

單例模式 (Singleton Pattern)

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

• 單例模式確保某一個(gè)類只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例，這個(gè)類稱為單例類，它提供全局訪問的方法。單例模式的要點(diǎn)有三個(gè)：一是某個(gè)類只能有一個(gè)實(shí)例；二是它必須自行創(chuàng)建這個(gè)實(shí)例；三是它必須自行向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。單例模式是一種對(duì)象創(chuàng)建型模式。
• 單例模式只包含一個(gè)單例角色：在單例類的內(nèi)部實(shí)現(xiàn)只生成一個(gè)實(shí)例，同時(shí)它提供一個(gè)靜態(tài)的工廠方法，讓客戶可以使用它的唯一實(shí)例；為了防止在外部對(duì)其實(shí)例化，將其構(gòu)造函數(shù)設(shè)計(jì)為私有。
• 單例模式的目的是保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。單例類擁有一個(gè)私有構(gòu)造函數(shù)，確保用戶無法通過 new 關(guān)鍵字直接實(shí)例化它。除此之外，該模式中包含一個(gè)靜態(tài)私有成員變量與靜態(tài)公有的工廠方法。該工廠方法負(fù)責(zé)檢驗(yàn)實(shí)例的存在性并實(shí)例化自己，然后存儲(chǔ)在靜態(tài)成員變量中，以確保只有一個(gè)實(shí)例被創(chuàng)建。
• 單例模式的主要優(yōu)點(diǎn)在于提供了對(duì)唯一實(shí)例的受控訪問并可以節(jié)約系統(tǒng)資源；其主要缺點(diǎn)在于因?yàn)槿鄙俪橄髮佣y以擴(kuò)展，且單例類職責(zé)過重。
• 單例模式適用情況包括：系統(tǒng)只需要一個(gè)實(shí)例對(duì)象；客戶調(diào)用類的單個(gè)實(shí)例只允許使用一個(gè)公共訪問點(diǎn)。

簡(jiǎn)單工廠模式 (Simple Factory Pattern)

簡(jiǎn)單工廠模式(Simple Factory Pattern)：定義一個(gè)工廠類，它可以根據(jù)參數(shù)的不同返回不同類的實(shí)例，被創(chuàng)建的實(shí)例通常都具有共同的父類。因?yàn)樵诤?jiǎn)單工廠模式中用于創(chuàng)建實(shí)例的方法是靜態(tài)(static)方法，因此簡(jiǎn)單工廠模式又被稱為靜態(tài)工廠方法(Static Factory Method)模式。它屬于類創(chuàng)建型模式。

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

工廠方法模式 (Factory Method Pattern)

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

• 工廠方法模式又稱為工廠模式，它屬于類創(chuàng)建型模式。在工廠方法模式中，工廠父類負(fù)責(zé)定義創(chuàng)建產(chǎn)品對(duì)象的公共接口，而工廠子類則負(fù)責(zé)生成具體的產(chǎn)品對(duì)象，這樣做的目的是將產(chǎn)品類的實(shí)例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應(yīng)該實(shí)例化哪一個(gè)具體產(chǎn)品類。
• 工廠方法模式包含四個(gè)角色：抽象產(chǎn)品是定義產(chǎn)品的接口，是工廠方法模式所創(chuàng)建對(duì)象的超類型，即產(chǎn)品對(duì)象的共同父類或接口；具體產(chǎn)品實(shí)現(xiàn)了抽象產(chǎn)品接口，某種類型的具體產(chǎn)品由專門的具體工廠創(chuàng)建，它們之間往往一一對(duì)應(yīng)；抽象工廠中聲明了工廠方法，用于返回一個(gè)產(chǎn)品，它是工廠方法模式的核心，任何在模式中創(chuàng)建對(duì)象的工廠類都必須實(shí)現(xiàn)該接口；具體工廠是抽象工廠類的子類，實(shí)現(xiàn)了抽象工廠中定義的工廠方法，并可由客戶調(diào)用，返回一個(gè)具體產(chǎn)品類的實(shí)例。
• 工廠方法模式是簡(jiǎn)單工廠模式的進(jìn)一步抽象和推廣。由于使用了面向?qū)ο蟮亩鄳B(tài)性，工廠方法模式保持了簡(jiǎn)單工廠模式的優(yōu)點(diǎn)，而且克服了它的缺點(diǎn)。在工廠方法模式中，核心的工廠類不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建工作交給子類去做。這個(gè)核心類僅僅負(fù)責(zé)給出具體工廠必須實(shí)現(xiàn)的接口，而不負(fù)責(zé)產(chǎn)品類被實(shí)例化這種細(xì)節(jié)，這使得工廠方法模式可以允許系統(tǒng)在不修改工廠角色的情況下引進(jìn)新產(chǎn)品。
• 工廠方法模式的主要優(yōu)點(diǎn)是增加新的產(chǎn)品類時(shí)無須修改現(xiàn)有系統(tǒng)，并封裝了產(chǎn)品對(duì)象的創(chuàng)建細(xì)節(jié)，系統(tǒng)具有良好的靈活性和可擴(kuò)展性；其缺點(diǎn)在于增加新產(chǎn)品的同時(shí)需要增加新的工廠，導(dǎo)致系統(tǒng)類的個(gè)數(shù)成對(duì)增加，在一定程度上增加了系統(tǒng)的復(fù)雜性。
• 工廠方法模式適用情況包括：一個(gè)類不知道它所需要的對(duì)象的類；一個(gè)類通過其子類來指定創(chuàng)建哪個(gè)對(duì)象；將創(chuàng)建對(duì)象的任務(wù)委托給多個(gè)工廠子類中的某一個(gè)，客戶端在使用時(shí)可以無須關(guān)心是哪一個(gè)工廠子類創(chuàng)建產(chǎn)品子類，需要時(shí)再動(dòng)態(tài)指定。

抽象工廠模式 (Abstract Factory Pattern)

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

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

原型模式 (Prototype Pattern)

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

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

建造者模式 (Builder Pattern)

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

• 建造者模式將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。建造者模式是一步一步創(chuàng)建一個(gè)復(fù)雜的對(duì)象，它允許用戶只通過指定復(fù)雜對(duì)象的類型和內(nèi)容就可以構(gòu)建它們，用戶不需要知道內(nèi)部的具體構(gòu)建細(xì)節(jié)。建造者模式屬于對(duì)象創(chuàng)建型模式。
• 建造者模式包含如下四個(gè)角色：抽象建造者為創(chuàng)建一個(gè)產(chǎn)品對(duì)象的各個(gè)部件指定抽象接口；具體建造者實(shí)現(xiàn)了抽象建造者接口，實(shí)現(xiàn)各個(gè)部件的構(gòu)造和裝配方法，定義并明確它所創(chuàng)建的復(fù)雜對(duì)象，也可以提供一個(gè)方法返回創(chuàng)建好的復(fù)雜產(chǎn)品對(duì)象；產(chǎn)品角色是被構(gòu)建的復(fù)雜對(duì)象，包含多個(gè)組成部件；指揮者負(fù)責(zé)安排復(fù)雜對(duì)象的建造次序，指揮者與抽象建造者之間存在關(guān)聯(lián)關(guān)系，可以在其 construct() 建造方法中調(diào)用建造者對(duì)象的部件構(gòu)造與裝配方法，完成復(fù)雜對(duì)象的建造。
• 在建造者模式的結(jié)構(gòu)中引入了一個(gè)指揮者類，該類的作用主要有兩個(gè)：一方面它隔離了客戶與生產(chǎn)過程；另一方面它負(fù)責(zé)控制產(chǎn)品的生成過程。指揮者針對(duì)抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過指揮者類調(diào)用建造者的相關(guān)方法，返回一個(gè)完整的產(chǎn)品對(duì)象。
• 建造者模式的主要優(yōu)點(diǎn)在于客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)，將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過程解耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對(duì)象，每一個(gè)具體建造者都相對(duì)獨(dú)立，而與其他的具體建造者無關(guān)，因此可以很方便地替換具體建造者或增加新的具體建造者，符合“開閉原則”，還可以更加精細(xì)地控制產(chǎn)品的創(chuàng)建過程；其主要缺點(diǎn)在于由于建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點(diǎn)，其組成部分相似，因此其使用范圍受到一定的限制，如果產(chǎn)品的內(nèi)部變化復(fù)雜，可能會(huì)導(dǎo)致需要定義很多具體建造者類來實(shí)現(xiàn)這種變化，導(dǎo)致系統(tǒng)變得很龐大。
• 建造者模式適用情況包括：需要生成的產(chǎn)品對(duì)象有復(fù)雜的內(nèi)部結(jié)構(gòu)，這些產(chǎn)品對(duì)象通常包含多個(gè)成員屬性；需要生成的產(chǎn)品對(duì)象的屬性相互依賴，需要指定其生成順序；對(duì)象的創(chuàng)建過程獨(dú)立于創(chuàng)建該對(duì)象的類；隔離復(fù)雜對(duì)象的創(chuàng)建和使用，并使得相同的創(chuàng)建過程可以創(chuàng)建不同類型的產(chǎn)品。

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

適配器模式 (Adapter Pattern)

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

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

橋接模式 (Bridge Pattern)

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

• 橋接模式包含如下四個(gè)角色：抽象類中定義了一個(gè)實(shí)現(xiàn)類接口類型的對(duì)象并可以維護(hù)該對(duì)象；擴(kuò)充抽象類擴(kuò)充由抽象類定義的接口，它實(shí)現(xiàn)了在抽象類中定義的抽象業(yè)務(wù)方法，在擴(kuò)充抽象類中可以調(diào)用在實(shí)現(xiàn)類接口中定義的業(yè)務(wù)方法；實(shí)現(xiàn)類接口定義了實(shí)現(xiàn)類的接口，實(shí)現(xiàn)類接口僅提供基本操作，而抽象類定義的接口可能會(huì)做更多更復(fù)雜的操作；具體實(shí)現(xiàn)類實(shí)現(xiàn)了實(shí)現(xiàn)類接口并且具體實(shí)現(xiàn)它，在不同的具體實(shí)現(xiàn)類中提供基本操作的不同實(shí)現(xiàn)，在程序運(yùn)行時(shí)，具體實(shí)現(xiàn)類對(duì)象將替換其父類對(duì)象，提供給客戶端具體的業(yè)務(wù)操作方法。
• 在橋接模式中，抽象化(Abstraction)與實(shí)現(xiàn)化(Implementation)脫耦，它們可以沿著各自的維度獨(dú)立變化。
• 橋接模式的主要優(yōu)點(diǎn)是分離抽象接口及其實(shí)現(xiàn)部分，是比多繼承方案更好的解決方法，橋接模式還提高了系統(tǒng)的可擴(kuò)充性，在兩個(gè)變化維度中任意擴(kuò)展一個(gè)維度，都不需要修改原有系統(tǒng)，實(shí)現(xiàn)細(xì)節(jié)對(duì)客戶透明，可以對(duì)用戶隱藏實(shí)現(xiàn)細(xì)節(jié)；其主要缺點(diǎn)是增加系統(tǒng)的理解與設(shè)計(jì)難度，且識(shí)別出系統(tǒng)中兩個(gè)獨(dú)立變化的維度并不是一件容易的事情。
• 橋接模式適用情況包括：需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個(gè)層次之間建立靜態(tài)的繼承聯(lián)系；抽象化角色和實(shí)現(xiàn)化角色可以以繼承的方式獨(dú)立擴(kuò)展而互不影響；一個(gè)類存在兩個(gè)獨(dú)立變化的維度，且這兩個(gè)維度都需要進(jìn)行擴(kuò)展；設(shè)計(jì)要求需要獨(dú)立管理抽象化角色和具體化角色；不希望使用繼承或因?yàn)槎鄬哟卫^承導(dǎo)致系統(tǒng)類的個(gè)數(shù)急劇增加的系統(tǒng)。

組合模式 (Composite Pattern)

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

• 組合模式包含三個(gè)角色：抽象構(gòu)件可以是接口或抽象類，為葉子構(gòu)件和容器構(gòu)件對(duì)象聲明接口，在該角色中可以包含所有子類共有行為的聲明和實(shí)現(xiàn)；葉子構(gòu)件表示葉子節(jié)點(diǎn)對(duì)象，葉子節(jié)點(diǎn)沒有子節(jié)點(diǎn)，它實(shí)現(xiàn)了在抽象構(gòu)件中定義的行為；容器構(gòu)件表示容器節(jié)點(diǎn)對(duì)象，容器節(jié)點(diǎn)包含子節(jié)點(diǎn)，其子節(jié)點(diǎn)可以是葉子節(jié)點(diǎn)，也可以是容器節(jié)點(diǎn)，它提供一個(gè)集合用于存儲(chǔ)子節(jié)點(diǎn)，實(shí)現(xiàn)了在抽象構(gòu)件中定義的行為，包括那些訪問及管理子構(gòu)件的方法，在其業(yè)務(wù)方法中可以遞歸調(diào)用其子節(jié)點(diǎn)的業(yè)務(wù)方法。
• 組合模式的關(guān)鍵是定義了一個(gè)抽象構(gòu)件類，它既可以代表葉子，又可以代表容器，而客戶端針對(duì)該抽象構(gòu)件類進(jìn)行編程，無須知道它到底表示的是葉子還是容器，可以對(duì)其進(jìn)行統(tǒng)一處理。
• 組合模式使用面向?qū)ο蟮乃枷雭韺?shí)現(xiàn)樹形結(jié)構(gòu)的構(gòu)建與處理，描述了如何將容器對(duì)象和葉子對(duì)象進(jìn)行遞歸組合，實(shí)現(xiàn)簡(jiǎn)單，靈活性好。
• 組合模式的主要優(yōu)點(diǎn)是清楚地定義分層次的復(fù)雜對(duì)象，方便對(duì)整個(gè)層次結(jié)構(gòu)進(jìn)行控制；客戶端可以一致地使用一個(gè)組合結(jié)構(gòu)或其中單個(gè)對(duì)象，簡(jiǎn)化了客戶端代碼；增加新的容器構(gòu)件和葉子構(gòu)件都很方便，無須對(duì)現(xiàn)有類庫進(jìn)行任何修改，符合“開閉原則”。其主要缺點(diǎn)是在增加新構(gòu)件時(shí)很難對(duì)容器中的構(gòu)件類型進(jìn)行限制。
• 組合模式適用情況包括：在具有整體和部分的層次結(jié)構(gòu)中，希望通過一種方式忽略整體與部分的差異，客戶端可以一致地對(duì)待它們；在一個(gè)使用面向?qū)ο笳Z言開發(fā)的系統(tǒng)中需要處理一個(gè)樹形結(jié)構(gòu)；在一個(gè)系統(tǒng)中能夠分離出葉子對(duì)象和容器對(duì)象，而且它們的類型不固定，需要增加一些新的類型。

裝飾模式 (Decorator Pattern)

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

• 裝飾模式包含四個(gè)角色：抽象構(gòu)件定義了對(duì)象的接口，可以給這些對(duì) 象動(dòng)態(tài)增加職責(zé)（方法）；具體構(gòu)件定義了具體的構(gòu)件對(duì)象，實(shí)現(xiàn)了 在抽象構(gòu)件中聲明的方法，裝飾器可以給它增加額外的職責(zé)（方法）； 抽象裝飾類是抽象構(gòu)件類的子類，用于給具體構(gòu)件增加職責(zé)，但是具體職責(zé)在其子類中實(shí)現(xiàn)；具體裝飾類是抽象裝飾類的子類，負(fù)責(zé)向構(gòu)件添加新的職責(zé)。
• 使用裝飾模式來實(shí)現(xiàn)擴(kuò)展比繼承更加靈活，它以對(duì)客戶透明的方式動(dòng)態(tài)地給一個(gè)對(duì)象附加更多的責(zé)任。裝飾模式可以在不需要?jiǎng)?chuàng)造更多子類的情況下，將對(duì)象的功能加以擴(kuò)展。
• 裝飾模式的主要優(yōu)點(diǎn)在于可以提供比繼承更多的靈活性，可以通過一種動(dòng)態(tài)的方式來擴(kuò)展一個(gè)對(duì)象的功能，并通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創(chuàng)造出很多不同行為的組合，而且具體構(gòu)件類與具體裝飾類可以獨(dú)立變化，用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類；其主要缺點(diǎn)在于使用裝飾模式進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)將產(chǎn)生很多小對(duì)象，而且裝飾模式比繼承更加易于出錯(cuò)，排錯(cuò)也很困難，對(duì)于多次裝飾的對(duì)象，調(diào)試時(shí)尋找錯(cuò)誤可能需要逐級(jí)排查，較為煩瑣。
• 裝飾模式適用情況包括：在不影響其他對(duì)象的情況下，以動(dòng)態(tài)、透明的方式給單個(gè)對(duì)象添加職責(zé)；需要?jiǎng)討B(tài)地給一個(gè)對(duì)象增加功能，這些功能也可以動(dòng)態(tài)地被撤銷；當(dāng)不能采用繼承的方式對(duì)系統(tǒng)進(jìn)行擴(kuò)充或者采用繼承不利于系統(tǒng)擴(kuò)展和維護(hù)時(shí)。
• 裝飾模式可分為透明裝飾模式和半透明裝飾模式：在透明裝飾模式中，要求客戶端完全針對(duì)抽象編程，裝飾模式的透明性要求客戶端程序不應(yīng)該聲明具體構(gòu)件類型和具體裝飾類型，而應(yīng)該全部聲明為抽象構(gòu)件類型；半透明裝飾模式允許用戶在客戶端聲明具體裝飾者類型的對(duì)象，調(diào)用在具體裝飾者中新增的方法。

外觀模式 (Facade Pattern)

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

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

享元模式 (Flyweight Pattern)

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

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

代理模式 (Proxy Pattern)

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

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

3. 11 個(gè)行為型模式

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

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

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

命令模式 (Command Pattern)

命令模式(Command Pattern)：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使我們可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及支持可撤銷的操作。命令模式是一種對(duì)象行為型模式，其別名為動(dòng)作 (Action) 模式或事務(wù) (Transaction) 模式。

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

解釋器模式 (Interpreter Pattern)

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

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

迭代器模式 (Iterator Pattern)

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

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

中介者模式 (Mediator Pattern)

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

• 中介者模式包含四個(gè)角色：抽象中介者用于定義一個(gè)接口，該接口用于與各同事對(duì)象之間的通信；具體中介者是抽象中介者的子類，通過協(xié)調(diào)各個(gè)同事對(duì)象來實(shí)現(xiàn)協(xié)作行為，了解并維護(hù)它的各個(gè)同事對(duì)象的引用；抽象同事類定義各同事的公有方法；具體同事類是抽象同事類的子類，每一個(gè)同事對(duì)象都引用一個(gè)中介者對(duì)象；每一個(gè)同事對(duì)象在需要和其他同事對(duì)象通信時(shí)，先與中介者通信，通過中介者來間接完成與其他同事類的通信；在具體同事類中實(shí)現(xiàn)了在抽象同事類中定義的方法。
• 通過引入中介者對(duì)象，可以將系統(tǒng)的網(wǎng)狀結(jié)構(gòu)變成以中介者為中心的星形結(jié)構(gòu)，中介者承擔(dān)了中轉(zhuǎn)作用和協(xié)調(diào)作用。中介者類是中介者模式的核心，它對(duì)整個(gè)系統(tǒng)進(jìn)行控制和協(xié)調(diào)，簡(jiǎn)化了對(duì)象之間的交互，還可以對(duì)對(duì)象間的交互進(jìn)行進(jìn)一步的控制。
• 中介者模式的主要優(yōu)點(diǎn)在于簡(jiǎn)化了對(duì)象之間的交互，將各同事解耦，還可以減少子類生成，對(duì)于復(fù)雜的對(duì)象之間的交互，通過引入中介者，可以簡(jiǎn)化各同事類的設(shè)計(jì)和實(shí)現(xiàn)；中介者模式主要缺點(diǎn)在于具體中介者類中包含了同事之間的交互細(xì)節(jié)，可能會(huì)導(dǎo)致具體中介者類非常復(fù)雜，使得系統(tǒng)難以維護(hù)。
• 中介者模式適用情況包括：系統(tǒng)中對(duì)象之間存在復(fù)雜的引用關(guān)系，產(chǎn)生的相互依賴關(guān)系結(jié)構(gòu)混亂且難以理解；一個(gè)對(duì)象由于引用了其他很多對(duì)象并且直接和這些對(duì)象通信，導(dǎo)致難以復(fù)用該對(duì)象；想通過一個(gè)中間類來封裝多個(gè)類中的行為，而又不想生成太多的子類。

備忘錄模式 (Memento Pattern)

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

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

觀察者模式 (Observer Pattern)

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

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

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

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

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

策略模式 (Strategy Pattern)

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

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

模板方法模式 (Template Method Pattern)

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

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

訪問者模式 (Visitor Pattern)

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

• 訪問者模式包含五個(gè)角色：抽象訪問者為對(duì)象結(jié)構(gòu)中每一個(gè)具體元素類聲明一個(gè)訪問操作；具體訪問者實(shí)現(xiàn)了每個(gè)由抽象訪問者聲明的操作；抽象元素一般是抽象類或者接口，它定義一個(gè) accept() 方法，該方法通常以一個(gè)抽象訪問者作為參數(shù)；具體元素實(shí)現(xiàn)了 accept() 方法，在accept()方法中調(diào)用訪問者的訪問方法以便完成對(duì)一個(gè)元素的操作；對(duì)象結(jié)構(gòu)是一個(gè)元素的集合，它用于存放元素對(duì)象，并且提供了遍歷其內(nèi)部元素的方法。
• 訪問者模式中對(duì)象結(jié)構(gòu)存儲(chǔ)了不同類型的元素對(duì)象，以供不同訪問者訪問。訪問者模式包括兩個(gè)層次結(jié)構(gòu)，一個(gè)是訪問者層次結(jié)構(gòu)，提供了抽象訪問者和具體訪問者，一個(gè)是元素層次結(jié)構(gòu)，提供了抽象元素和具體元素。相同的訪問者可以以不同的方式訪問不同的元素，相同的元素可以接受不同訪問者以不同訪問方式訪問。在訪問者模式中，增加新的訪問者無須修改原有系統(tǒng)，系統(tǒng)具有較好的可擴(kuò)展性。
• 訪問者模式的主要優(yōu)點(diǎn)是增加新的訪問操作很方便，讓用戶能夠在不修改現(xiàn)有元素類層次結(jié)構(gòu)的情況下，定義作用于該層次結(jié)構(gòu)的操作；其缺點(diǎn)是增加新的元素類很困難，破壞了封裝性。
• 訪問者模式適用情景包括：個(gè)對(duì)象結(jié)構(gòu)包含多個(gè)類型的對(duì)象，希望對(duì)這些對(duì)象實(shí)施一些依賴其具體類型的操作；需要對(duì)一個(gè)對(duì)象結(jié)構(gòu)中的對(duì)象進(jìn)行很多不同的并且不相關(guān)的操作，而需要避免讓這些操作 “污染” 這些對(duì)象的類，也不希望在增加新操作時(shí)修改這些類；對(duì)象結(jié)構(gòu)中對(duì)象對(duì)應(yīng)的類很少改變，但經(jīng)常需要在此對(duì)象結(jié)構(gòu)上定義新的操作。

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