摘要：抽象工廠(chǎng)模式將具有共同主題的對(duì)象工廠(chǎng)分組。對(duì)可重用性和可維護(hù)性設(shè)計(jì)模式的高層考慮創(chuàng)造性模式工廠(chǎng)方法模式也稱(chēng)為虛擬構(gòu)造器意圖定義一個(gè)用于創(chuàng)建對(duì)象的接口，但讓子類(lèi)決定實(shí)例化哪個(gè)類(lèi)。

創(chuàng)造性模式

工廠(chǎng)方法模式創(chuàng)建對(duì)象而不指定要?jiǎng)?chuàng)建的確切類(lèi)。

抽象工廠(chǎng)模式將具有共同主題的對(duì)象工廠(chǎng)分組。

Builder模式通過(guò)分離構(gòu)造和表示來(lái)構(gòu)造復(fù)雜的對(duì)象。

結(jié)構(gòu)模式

Bridge將抽象從其實(shí)現(xiàn)中分離出來(lái)，這樣兩者可以獨(dú)立變化。

代理提供另一個(gè)對(duì)象的占位符來(lái)控制訪(fǎng)問(wèn)，降低成本并降低復(fù)雜性。

復(fù)合材料組成零個(gè)或多個(gè)相似的對(duì)象，以便它們可以作為一個(gè)對(duì)象進(jìn)行操作。

*行為模式

中介者可以通過(guò)成為唯一具有其方法詳細(xì)知識(shí)的課程，從而實(shí)現(xiàn)課堂間的松散耦合。

Observer是一種發(fā)布/訂閱模式，它允許許多觀(guān)察者對(duì)象查看事件。

訪(fǎng)問(wèn)者通過(guò)將方法的層次結(jié)構(gòu)移動(dòng)到一個(gè)對(duì)象中來(lái)將算法從對(duì)象結(jié)構(gòu)中分離出來(lái)。

責(zé)任鏈將命令委托給一系列處理對(duì)象。

命令創(chuàng)建封裝動(dòng)作和參數(shù)的對(duì)象。

對(duì)可重用性和可維護(hù)性設(shè)計(jì)模式的高層考慮

工廠(chǎng)方法模式
也稱(chēng)為“虛擬構(gòu)造器”

意圖：

定義一個(gè)用于創(chuàng)建對(duì)象的接口，但讓子類(lèi)決定實(shí)例化哪個(gè)類(lèi)。

工廠(chǎng)方法讓類(lèi)將實(shí)例化推遲到子類(lèi)。

什么時(shí)候應(yīng)該使用工廠(chǎng)方法？ ----當(dāng)一個(gè)類(lèi)：

無(wú)法預(yù)測(cè)它需要?jiǎng)?chuàng)建的對(duì)象的類(lèi)別

希望它的子類(lèi)指定它創(chuàng)建的對(duì)象

將責(zé)任委托給多個(gè)幫助者子類(lèi)中的一個(gè)，并且您需要本地化哪些幫助者是委托人的知識(shí)。

當(dāng)客戶(hù)不知道要?jiǎng)?chuàng)建哪個(gè)具體類(lèi)的實(shí)例，或者不想在客戶(hù)代碼中指明具體創(chuàng)建的實(shí)例時(shí)，用工廠(chǎng)方法。定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓其子類(lèi)來(lái)決定實(shí)例化哪一個(gè)類(lèi) ，從而使一個(gè)類(lèi)的實(shí)例化延遲到其子類(lèi)。

優(yōu)點(diǎn)：

消除了將特定于應(yīng)用程序的類(lèi)綁定到代碼的需要。

代碼只處理產(chǎn)品接口（Trace），因此它可以與任何用戶(hù)定義的ConcreteProduct（FileTrace，SystemTrace）

潛在的缺點(diǎn)

客戶(hù)可能必須創(chuàng)建Creator的子類(lèi)，以便他們可以創(chuàng)建某個(gè)ConcreteProduct。

如果客戶(hù)無(wú)論如何都要繼承創(chuàng)造者的話(huà)，這是可以接受的，但如果不是，那么客戶(hù)必須處理另一個(gè)進(jìn)化點(diǎn)。

Open-Closed Principle（OCP） - 對(duì)擴(kuò)展的開(kāi)放，對(duì)修改已有代碼的封閉

抽象工廠(chǎng)模式

示例1：考慮一個(gè)用戶(hù)界面工具包，它支持不同操作系統(tǒng)的多個(gè)外觀(guān)和感覺(jué)標(biāo)準(zhǔn)：一個(gè)UI，包含多個(gè)窗口控件，這些控件在不同的OS中實(shí)現(xiàn)不同

如何編寫(xiě)單個(gè)用戶(hù)界面，并使這些界面在這些窗口管理器的不同外觀(guān)和感覺(jué)標(biāo)準(zhǔn)之間移植？

示例2：考慮支持不同控制系統(tǒng)的智能住宅的設(shè)施管理系統(tǒng)：一個(gè)倉(cāng)庫(kù)類(lèi)，要控制多個(gè)設(shè)備，這些設(shè)備的制造商各有不同，控制接口有差異

如何編寫(xiě)?yīng)毩⒂谥圃焐痰膯蝹€(gè)控制系統(tǒng)？

抽象工廠(chǎng)模式：提供接口以創(chuàng)建一組相關(guān)/相互依賴(lài)的對(duì)象，但不需要指明其具體類(lèi)。

名稱(chēng)：抽象工廠(chǎng)（或工具包）
意圖：允許獨(dú)立于實(shí)現(xiàn)創(chuàng)建相關(guān)對(duì)象的家族
方法：使用工廠(chǎng)返回可用于創(chuàng)建相關(guān)對(duì)象集的工廠(chǎng)。

適用性

獨(dú)立于初始化或表示的不同系列組件（產(chǎn)品）

必須以互斥和一致的方式使用

隱藏來(lái)自客戶(hù)的多個(gè)家庭的存在

制造商獨(dú)立

應(yīng)對(duì)即將到來(lái)的變化

筆記

Abstract Factory創(chuàng)建的不是一個(gè)完整產(chǎn)品，而是“遵循固定搭配規(guī)則的多類(lèi)產(chǎn)品的實(shí)例”，得到的結(jié)果是：多個(gè)不同產(chǎn)品的對(duì)象，各產(chǎn)品創(chuàng)建過(guò)程對(duì)客戶(hù)可見(jiàn)，但“搭配”不能改變。
本質(zhì)上，Abstract Factory是把多類(lèi)產(chǎn)品的工廠(chǎng)方法組合在一起

例如

GraphPoet由Word列表和WordNeighborhood列表組成
NetworkTopology由計(jì)算機(jī)/服務(wù)器/路由器列表和NetworkConnection列表組成
換句話(huà)說(shuō)，Vertex和Edge的對(duì)象創(chuàng)建密切相關(guān)，但不應(yīng)該是獨(dú)立的。 Vertex和Edge的子類(lèi)，要有固定搭配，不能隨意組合

抽象工廠(chǎng)vs工廠(chǎng)方法

工廠(chǎng)方法僅用于創(chuàng)建一個(gè)產(chǎn)品，但抽象工廠(chǎng)用于創(chuàng)建相關(guān)或依賴(lài)產(chǎn)品系列。

創(chuàng)建一個(gè)對(duì)象vs創(chuàng)建多個(gè)類(lèi)型的對(duì)象

工廠(chǎng)方法模式向客戶(hù)端公開(kāi)創(chuàng)建對(duì)象的方法，而抽象工廠(chǎng)則顯示由這些工廠(chǎng)方法組成的一系列相關(guān)對(duì)象。

一個(gè)工廠(chǎng)方法vs多個(gè)工廠(chǎng)方法

抽象工廠(chǎng)模式使用組合來(lái)將創(chuàng)建對(duì)象的責(zé)任委派給另一個(gè)類(lèi)，而工廠(chǎng)方法模式使用繼承并依賴(lài)于派生類(lèi)或子類(lèi)來(lái)創(chuàng)建對(duì)象。

使用組合/委派vs使用繼承/子類(lèi)型

構(gòu)造器模式

構(gòu)造器模式：將復(fù)雜對(duì)象的構(gòu)造與其表示分開(kāi)，以便相同的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。創(chuàng)建復(fù)雜對(duì)象，包含多個(gè)組成部分

復(fù)雜對(duì)象的構(gòu)建在多個(gè)表示中很常見(jiàn)

示例：將文檔轉(zhuǎn)換為多種不同的格式

寫(xiě)出文件的步驟是相同的

每一步的細(xì)節(jié)取決于格式

就像你在麥當(dāng)勞點(diǎn)餐一樣！

途徑

構(gòu)建算法由單個(gè)類(lèi)（“導(dǎo)演”）指定

算法的抽象步驟（每個(gè)部分一個(gè)）由接口（“構(gòu)造器”）指定

每個(gè)表示都提供了界面的具體實(shí)現(xiàn)（“實(shí)際構(gòu)造者”）

注意：客戶(hù)端要的不是一堆零散的對(duì)象（抽象工廠(chǎng)那樣的結(jié)果），而是一個(gè)完整的產(chǎn)品，客戶(hù)端不關(guān)心其中的細(xì)節(jié)組成部分是什么，如何創(chuàng)建

比較：抽象工廠(chǎng)vs構(gòu)造器

Abstract Factory創(chuàng)建的不是一個(gè)完整產(chǎn)品，而是“遵循固定搭配規(guī)則的多類(lèi)產(chǎn)品實(shí)例”，得到的結(jié)果是：多個(gè)不同產(chǎn)品的實(shí)例對(duì)象，各產(chǎn)品創(chuàng)建過(guò)程對(duì)客戶(hù)可見(jiàn)，但“搭配”不能改變。

專(zhuān)注于產(chǎn)品系列（類(lèi)似的產(chǎn)品類(lèi)型）

不隱藏構(gòu)造過(guò)程

Builder創(chuàng)建的是一個(gè)完整的產(chǎn)品，有多個(gè)部分組成，客戶(hù)不需要了解每個(gè)部分是怎么創(chuàng)建，各個(gè)部分怎么組合，最終得到一個(gè)產(chǎn)品的完整對(duì)象

基礎(chǔ)產(chǎn)品需要構(gòu)建為系統(tǒng)的一部分，但創(chuàng)建非常復(fù)雜（產(chǎn)品組合）

復(fù)雜產(chǎn)品的構(gòu)造會(huì)不時(shí)變化

隱藏用戶(hù)的創(chuàng)建過(guò)程

抽象工廠(chǎng)和構(gòu)造器可以很好地協(xié)同工作，適用于多種復(fù)雜產(chǎn)品系列

例如

GraphPoet由Word列表和WordNeighborhood列表組成
NetworkTopology由計(jì)算機(jī)/服務(wù)器/路由器列表和NetworkConnection列表組成
換句話(huà)說(shuō)，ConcreteGraph的對(duì)象創(chuàng)建由Vertex和Edge子類(lèi)型的對(duì)象創(chuàng)建組成。 四個(gè)圖應(yīng)用都要?jiǎng)?chuàng)建圖對(duì)象，要為不同應(yīng)用建立出不同的頂點(diǎn)列表和邊列表。

比較：模板方法vs構(gòu)造器

模板方法：行為模式，目標(biāo)是為了復(fù)用算法的公共結(jié)構(gòu)（次序）

定義了一個(gè)操作中算法的骨架（步），而將具體步驟的實(shí)現(xiàn)延遲到子類(lèi)中，從而復(fù)用算法的結(jié)構(gòu)并可重新定義算法的某些特定步驟的實(shí)現(xiàn)邏輯。

復(fù)用算法骨架，強(qiáng)調(diào)步驟的次序 - 子類(lèi)override算法步驟

Builder：一種創(chuàng)造模式，目標(biāo)是“創(chuàng)建復(fù)雜對(duì)象”，靈活擴(kuò)展

將一個(gè)復(fù)雜對(duì)象的構(gòu)造方法與對(duì)象內(nèi)部的具體表示分離出來(lái)，同樣的構(gòu)造方法可以建立不同的表現(xiàn)。

不強(qiáng)調(diào)復(fù)雜對(duì)象內(nèi)部各部分的“次序”

子類(lèi)override復(fù)雜對(duì)象內(nèi)部各部分的“創(chuàng)建”

適應(yīng)變化：通過(guò)派生新的builder來(lái)構(gòu)造新的對(duì)象（即新的內(nèi)部表示），OCP

橋接模式

適用性

用不同的實(shí)現(xiàn)去耦合抽象概念

實(shí)施可能會(huì)在運(yùn)行時(shí)切換

實(shí)施變更不應(yīng)影響客戶(hù)

從客戶(hù)端隱藏類(lèi)的界面

結(jié)構(gòu)：使用兩個(gè)層次結(jié)構(gòu)

適合客戶(hù)的邏輯

為不同的實(shí)現(xiàn)物理一個(gè)

對(duì)象：提高可擴(kuò)展性

邏輯類(lèi)和物理類(lèi)獨(dú)立變化

隱藏來(lái)自客戶(hù)的實(shí)施細(xì)節(jié)

橋接模式是OOP最基本的結(jié)構(gòu)模式，通過(guò)委托+繼承建立兩個(gè)具體類(lèi)之間的關(guān)系（DIP依賴(lài)轉(zhuǎn)置，抽象依賴(lài)于抽象）

橋接模式與策略模式

橋接：結(jié)構(gòu)模式，強(qiáng)調(diào)雙方的運(yùn)行時(shí)委派連接

結(jié)構(gòu)模式表明對(duì)象組成或關(guān)聯(lián)或繼承以形成更大對(duì)象的方式，即它們關(guān)注對(duì)象組成。

一個(gè)類(lèi)A的對(duì)象中有其他類(lèi)B的對(duì)象作為其組成部分，但A的對(duì)象具體綁定到B的哪個(gè)具體子類(lèi)的實(shí)現(xiàn)？在運(yùn)行時(shí)通過(guò)委托加以組合，并永久保存這種代理關(guān)系。

它將抽象和實(shí)現(xiàn)分離開(kāi)來(lái)，并允許兩者獨(dú)立地變化。

策略：行為模式，強(qiáng)調(diào)一方運(yùn)行時(shí)使用另一方的“算法”

行為模式處理算法或業(yè)務(wù)邏輯（而不是對(duì)象創(chuàng)建本身），即它們專(zhuān)注于對(duì)象之間的協(xié)作。

它使您能夠在運(yùn)行時(shí)在一系列算法中切換多種算法。

“算法”通常實(shí)現(xiàn)為“類(lèi)的某個(gè)方法”的形式，策略模式的目的并非在“調(diào)用算法的類(lèi)”與“被調(diào)用算法所在的類(lèi)”之間建立起永久聯(lián)系，而只是幫助前者臨時(shí)使用后者中的“算法”，前者無(wú)需永久保存后者的實(shí)例。

策略：使用螺絲刀的時(shí)候，針對(duì)不同的工作任務(wù)，選取不同的“刀頭”，但目的并非將螺絲刀與刀頭組合起來(lái)建立永久的團(tuán)隊(duì)，而只是臨時(shí)通過(guò)委派完成任務(wù)（即調(diào)用刀頭的“算法”），然后二者再無(wú)聯(lián)系。

橋接：類(lèi)A需要完成“通訊”功能，它有一個(gè)組成部分Device類(lèi)，這是個(gè)抽象接口（模式中的實(shí)現(xiàn)者），有多種實(shí)現(xiàn)方式（PC，tablet，phone，即ConcreteImplementor），該模式在運(yùn)行時(shí)為類(lèi)A的具體子類(lèi)型實(shí)例設(shè)定具體的Device的具體實(shí)現(xiàn)（強(qiáng)調(diào)對(duì)A和Device兩個(gè)抽象類(lèi)的各自實(shí)例之間如何建立委托），進(jìn)而在其他各項(xiàng)功能中利用其通訊功能（這不再是橋接模式關(guān)注的目標(biāo)）。

代理模式

代理模式動(dòng)機(jī)

目標(biāo)：

防止客戶(hù)直接訪(fǎng)問(wèn)對(duì)象

通過(guò)充當(dāng)傳遞實(shí)體或占位符對(duì)象來(lái)允許進(jìn)行對(duì)象級(jí)訪(fǎng)問(wèn)控制。

解決方案：

使用一個(gè)稱(chēng)為代理的附加對(duì)象

客戶(hù)端只能通過(guò)代理訪(fǎng)問(wèn)受保護(hù)的對(duì)象

代理跟蹤受保護(hù)對(duì)象的狀態(tài)和/或位置

某個(gè)對(duì)象比較“敏感”/“私密”/“貴重”，不希望被客戶(hù)端直接訪(fǎng)問(wèn)到，故設(shè)置代理，在二者之間建立防火墻。

代理模式：3種類(lèi)型

信息緩存（“遠(yuǎn)程代理”）

代理對(duì)象是不同地址空間中對(duì)象的本地代理

如果信息沒(méi)有經(jīng)常變化，那么很好

Standin（“虛擬代理”）

對(duì)象創(chuàng)建成本太高或者下載成本太高。

如果真正的對(duì)象不被太頻繁地訪(fǎng)問(wèn)，那么很好

訪(fǎng)問(wèn)控制（“保護(hù)代理”）

代理對(duì)象為真實(shí)對(duì)象提供保護(hù)

好的時(shí)候，不同的演員應(yīng)該對(duì)同一個(gè)對(duì)象有不同的訪(fǎng)問(wèn)和查看權(quán)限

示例：管理員，教師和學(xué)生訪(fǎng)問(wèn)的成績(jī)信息。

代理與適配器

適配器：結(jié)構(gòu)模式，目的是將類(lèi)/庫(kù)A的接口更改為客戶(hù)端B的期望。
目的：消除不兼容，目的是B以客戶(hù)端期望的統(tǒng)一的方式與A建立起聯(lián)系。

典型的實(shí)現(xiàn)是一個(gè)包裝類(lèi)或一組類(lèi)。

目的不是為了方便將來(lái)的界面更改，而是當(dāng)前的界面不兼容。

代理：行為模式，也使用包裝類(lèi)，但其目的是為實(shí)際資源創(chuàng)建一個(gè)替身。
目的：隔離對(duì)復(fù)雜對(duì)象的訪(fǎng)問(wèn)，降低難度/代價(jià)，定位在“訪(fǎng)問(wèn)/使用行為”

真正的資源駐留在遠(yuǎn)程計(jì)算機(jī)上（代理方便與遠(yuǎn)程資源的交互）

真正的資源創(chuàng)建成本很高（代理確保成本不會(huì)發(fā)生，除非/直到真正需要）

代理提供了替代它所代表的真實(shí)資源的插入替代品，因此它必須提供相同的接口。

組合模式

問(wèn)題：

應(yīng)用程序需要操作“原始”和“復(fù)合”對(duì)象的分層集合。

原始對(duì)象的處理是單向處理的，處理復(fù)合對(duì)象的處理方式不同。

在嘗試處理每個(gè)對(duì)象之前必須查詢(xún)每個(gè)對(duì)象的“類(lèi)型”是不可取的。

意圖：將對(duì)象組成樹(shù)結(jié)構(gòu)以表示整體部分層次結(jié)構(gòu)。

組合模式讓客戶(hù)可以統(tǒng)一處理單個(gè)物體和物體的組合。

遞歸組合

“目錄包含條目，每個(gè)條目都可以是目錄?！?/p>

一對(duì)多“has a”之上“is a”層次

組合策略

包含菜單項(xiàng)的菜單，每個(gè)菜單項(xiàng)都可以是菜單。
包含小部件的行列GUI布局管理器，每個(gè)小部件都可以是行列GUI布局管理器。
包含文件的目錄，每個(gè)文件都可以是一個(gè)目錄。
包含元素的容器，其中每個(gè)容器都可以是容器。
樹(shù)結(jié)構(gòu)

復(fù)合vs裝飾器

復(fù)合：結(jié)構(gòu)模式，允許您以允許外部代碼將整個(gè)結(jié)構(gòu)視為單個(gè)實(shí)體的方式構(gòu)建分層結(jié)構(gòu)（樹(shù)）。目的是在同類(lèi)型的對(duì)象之間建立起樹(shù)型層次結(jié)構(gòu)，一個(gè)上層對(duì)象可包含多個(gè)下層對(duì)象

葉實(shí)體的接口與復(fù)合實(shí)體的實(shí)體完全相同。

復(fù)合結(jié)構(gòu)中的所有元素都具有相同的界面，即使有些元素是葉節(jié)點(diǎn)，而其他元素是整個(gè)結(jié)構(gòu)。

裝飾器：結(jié)構(gòu)模式，也允許一個(gè)實(shí)體完全包含另一個(gè)實(shí)體，以便使用裝飾器看起來(lái)與包含的實(shí)體相同。強(qiáng)調(diào)的是同類(lèi)型對(duì)象之間的“特性增加”問(wèn)題，它們之間是平等的，區(qū)別在于“擁有特性”的多少，每次裝飾只能作用于一個(gè)對(duì)象。

這允許修飾器修改其封裝的行為或內(nèi)容，而不改變實(shí)體的外觀(guān)。

觀(guān)察者模式

問(wèn)題：依賴(lài)的狀態(tài)必須與主人的狀態(tài)一致

解決方案：定義四種對(duì)象：

摘要主題：保留家屬名單; 當(dāng)主人更改時(shí)通知他們

抽象觀(guān)察者：定義更新依賴(lài)者的協(xié)議

具體主題：為受撫養(yǎng)人管理數(shù)據(jù); 當(dāng)主人更改時(shí)通知他們

具體的觀(guān)察者：在收到更新消息后獲得新的主體狀態(tài)

“粉絲”對(duì)“偶像”感興趣，希望隨時(shí)得知偶像的一舉一動(dòng)
粉絲到偶像那里注冊(cè)，偶像一旦有新聞發(fā)生，就推送給已注冊(cè)的粉絲（回調(diào)粉絲的特定功能）

建模對(duì)象之間的一對(duì)多依賴(lài)關(guān)系

連接觀(guān)察對(duì)象的狀態(tài)，主體與許多觀(guān)察對(duì)象，觀(guān)察者

用法：

保持冗余狀態(tài)的一致性

優(yōu)化一批更改以保持一致性

保持一致性的三個(gè)變體：

推送通知：每當(dāng)主題狀態(tài)改變時(shí)，所有觀(guān)察者都會(huì)收到通知

推送更新通知：主題還將已更改的狀態(tài)發(fā)送給觀(guān)察者

拉通知：觀(guān)察者詢(xún)問(wèn)對(duì)象的狀態(tài)

也稱(chēng)為發(fā)布 - 訂閱（Publish-ubscribe）。

優(yōu)點(diǎn)：

主體和觀(guān)察者之間的低耦合：主體不知道家屬

支持廣播：動(dòng)態(tài)添加和刪除觀(guān)察員

意外更新：由觀(guān)察者在計(jì)算上不受主題的控制

實(shí)施問(wèn)題

存儲(chǔ)觀(guān)察員列表：通常在主題中

觀(guān)察多個(gè)主題：通常將參數(shù)添加到update（）

誰(shuí)觸發(fā)更新：主體的狀態(tài)設(shè)置操作

訪(fǎng)客模式

訪(fǎng)問(wèn)者模式：允許在運(yùn)行時(shí)將一個(gè)或多個(gè)操作應(yīng)用于一組對(duì)象，將操作與對(duì)象結(jié)構(gòu)分離。 對(duì)特定類(lèi)型的對(duì)象的特定操作（訪(fǎng)問(wèn)），在運(yùn)行時(shí)將二者動(dòng)態(tài)綁定到一起，該操作可以靈活更改，無(wú)需更改被訪(fǎng)問(wèn)的類(lèi)

Visitor模式實(shí)際上做的是創(chuàng)建一個(gè)使用其他類(lèi)中的數(shù)據(jù)的外部類(lèi)。

如果操作邏輯改變了，那么我們只需要在訪(fǎng)問(wèn)者實(shí)現(xiàn)中進(jìn)行更改，而不是在所有項(xiàng)目類(lèi)中進(jìn)行更改。

本質(zhì)上：將數(shù)據(jù)和作用于數(shù)據(jù)上的某種/些特定操作分離開(kāi)來(lái)。

訪(fǎng)客與迭代器

迭代器：行為模式，用于順序訪(fǎng)問(wèn)聚集，而不暴露其基礎(chǔ)表示。 所以你可以在一個(gè)Iterator后面隱藏一個(gè)List或數(shù)組或類(lèi)似的聚合。
迭代器：以遍歷的方式訪(fǎng)問(wèn)集合數(shù)據(jù)而無(wú)需暴露其內(nèi)部表示，將“遍歷”這項(xiàng)功能委托到外部的迭代器對(duì)象。

訪(fǎng)問(wèn)者：行為模式，用于對(duì)元素結(jié)構(gòu)執(zhí)行操作而不改變?cè)乇旧淼膶?shí)現(xiàn)。
在特定ADT上執(zhí)行某種特定操作，但該操作不在A(yíng)DT內(nèi)部實(shí)現(xiàn)，而是委托到獨(dú)立的訪(fǎng)客對(duì)象，客戶(hù)端可靈活擴(kuò)展/改變?cè)L問(wèn)者的操作算法，而不影響ADT

策略vs訪(fǎng)客

訪(fǎng)客：行為模式
策略：行為模式

二者都是通過(guò)授權(quán)建立兩個(gè)對(duì)象的動(dòng)態(tài)聯(lián)系

但是Visitor強(qiáng)調(diào)是的外部定義某種對(duì)ADT的操作，該操作于A(yíng)DT自身關(guān)系不大（只是訪(fǎng)問(wèn)ADT），故ADT內(nèi)部只需要開(kāi)放accept 訪(fǎng)客）即可，客戶(hù)端通過(guò)它設(shè)定訪(fǎng)客操作并在外部調(diào)用。

而策略是強(qiáng)調(diào)是對(duì)ADT內(nèi)部某些要實(shí)現(xiàn)的功能的相應(yīng)算法的靈活替換。這些算法是ADT功能的重要組成部分，只不過(guò)是委托到外部戰(zhàn)略類(lèi)而已。

區(qū)別：訪(fǎng)客是站在外部客戶(hù)的角度，靈活增加對(duì)ADT的各種不同操作（哪怕ADT沒(méi)實(shí)現(xiàn)該操作），策略是站在內(nèi)部ADT的角度，靈活變化對(duì)其內(nèi)部功能的不同配置。

中介模式

使用中央控制器是中介模式的關(guān)鍵方面。

機(jī)場(chǎng)控制塔照看可以起飛的航班，并且所有的通信都是從飛機(jī)到控制塔完成的，而不是進(jìn)行飛機(jī)與飛機(jī)之間的通信。 多個(gè)對(duì)象之間要進(jìn)行交互，不是直接交互，而是通過(guò)mediator，實(shí)現(xiàn)消息的廣播，從而將對(duì)象之間松散耦合，利于變化

通過(guò)封裝不同對(duì)象集相互交互和通信的方式，允許松耦合。

允許每個(gè)對(duì)象的操作彼此獨(dú)立地變化。

觀(guān)察者模式與中介模式

觀(guān)察者模式：定義對(duì)象之間的一對(duì)多依賴(lài)關(guān)系，以便當(dāng)一個(gè)對(duì)象改變狀態(tài)時(shí)，它的所有依賴(lài)項(xiàng)都會(huì)被自動(dòng)通知和更新。
一組對(duì)象對(duì)另一個(gè)對(duì)象B的狀態(tài)變化感興趣（1對(duì)多），所以對(duì)其進(jìn)行觀(guān)察.B維持著一個(gè)對(duì)自己感興趣的對(duì)象列表，一旦自己發(fā)生變化，就通知這些對(duì)象。并不對(duì)等，一方只是“通知”，另一方接到通知后執(zhí)行特定行為。

中介模式：定義一個(gè)封裝一組對(duì)象如何交互的對(duì)象。介體通過(guò)讓對(duì)象明確地互相引用來(lái)促進(jìn)松散耦合，并且可以讓您獨(dú)立地改變它們的相互作用。
一組同類(lèi)型的對(duì)象，彼此之間相互發(fā)/收消息（多對(duì)多），不存在誰(shuí)觀(guān)察誰(shuí)的問(wèn)題，所有對(duì)象都對(duì)等。每個(gè)對(duì)象都維持一個(gè)中介，將通訊的任務(wù)委托給它，自己只負(fù)責(zé)發(fā)送和接收即可，無(wú)需了解其他物體，實(shí)現(xiàn)了“解耦”。

觀(guān)察者模式：自己來(lái)廣播，其他對(duì)象接收;
中介模式：第三方中介負(fù)責(zé)廣播（類(lèi)似于“郵件列表”）。

命令

意圖

將請(qǐng)求封裝為一個(gè)對(duì)象，從而讓您用不同的請(qǐng)求參數(shù)化客戶(hù)端，排隊(duì)或記錄請(qǐng)求，并支持可撤銷(xiāo)操作。

將“指令”封裝為對(duì)象，指令的所有細(xì)節(jié)對(duì)客戶(hù)隱藏，在指令內(nèi)對(duì)具體的ADT發(fā)出動(dòng)作（調(diào)用ADT的細(xì)節(jié)操作）

將“調(diào)用對(duì)象的方法”提升為完全對(duì)象狀態(tài)

面向?qū)ο蟮幕卣{(diào)

問(wèn)題

需要向?qū)ο蟀l(fā)出請(qǐng)求，而不知道請(qǐng)求的操作或請(qǐng)求的接收者。

客戶(hù)端希望執(zhí)行指令，但不想知道指令的細(xì)節(jié)，也不想知道指令的具體作用對(duì)象

命令將調(diào)用操作的對(duì)象與知道如何執(zhí)行操作的對(duì)象分離。

為了實(shí)現(xiàn)這種分離，設(shè)計(jì)人員創(chuàng)建了一個(gè)抽象基類(lèi)，它將接收者（對(duì)象）與動(dòng)作（指向成員函數(shù)的指針）進(jìn)行映射。 基類(lèi)包含一個(gè)execute（）方法，它只是簡(jiǎn)單地調(diào)用接收方的動(dòng)作。

每當(dāng)客戶(hù)端需要對(duì)象的“服務(wù)”時(shí)，Command對(duì)象的所有客戶(hù)端都通過(guò)簡(jiǎn)單地調(diào)用對(duì)象的虛擬execute（）方法將每個(gè)對(duì)象視為“黑盒子”。
將所有對(duì)客戶(hù)提供的指令與內(nèi)部執(zhí)行的ADT操作徹底分開(kāi)，指令對(duì)外看來(lái)是“黑盒” - 進(jìn)一步“變本加厲”的封裝！

一個(gè)Command類(lèi)包含以下的一些子集：

一個(gè)對(duì)象，一個(gè)應(yīng)用于該對(duì)象的方法，以及該方法應(yīng)用時(shí)傳遞的參數(shù)。

命令的“執(zhí)行”方法會(huì)導(dǎo)致碎片聚集在一起。

外觀(guān)與命令

外觀(guān)：結(jié)構(gòu)模式
命令：行為模式

均強(qiáng)調(diào)對(duì)某個(gè)復(fù)雜系統(tǒng)內(nèi)部提供的功能的“封裝”，對(duì)外提供簡(jiǎn)單的調(diào)用接口，簡(jiǎn)化客戶(hù)端的使用，“隱藏”細(xì)節(jié)。
命令：強(qiáng)調(diào)將指令封裝為了“對(duì)象”，提供了統(tǒng)一的對(duì)外接口（執(zhí)行）。
外觀(guān)：沒(méi)有顯式的“對(duì)象”，仍然通過(guò)類(lèi)的方法加以調(diào)用。

責(zé)任鏈模式

問(wèn)題

可能有多個(gè)“處理程序”或“處理元素”或“節(jié)點(diǎn)”對(duì)象，以及必須處理的請(qǐng)求流。

針對(duì)一個(gè)請(qǐng)求，可能有多個(gè)處理模塊

需要高效地處理請(qǐng)求，而無(wú)需硬連線(xiàn)處理程序關(guān)系和優(yōu)先級(jí)或請(qǐng)求到處理程序映射。

各種不確定情況存在，不能以“硬編碼”的方式指明按何種次序調(diào)用處理模塊
意圖

通過(guò)給予多個(gè)對(duì)象機(jī)會(huì)來(lái)處理請(qǐng)求，避免將請(qǐng)求的發(fā)送者耦合到它的接收者。

鏈接接收對(duì)象并沿著鏈傳遞請(qǐng)求，直到對(duì)象處理它為止。 使用包含許多可能的處理程序的單個(gè)處理管道啟動(dòng)和離開(kāi)請(qǐng)求。 具有遞歸遍歷的面向?qū)ο蟮逆湵怼?/p>

避免在請(qǐng)求方和各處理者之間的緊耦合：構(gòu)造流水線(xiàn)，請(qǐng)求在其上傳，直到被處理為止。

將處理元素封裝在“管道”抽象中; 并讓客戶(hù)在管道入口處“啟動(dòng)并離開(kāi)”他們的請(qǐng)求。
客戶(hù)端只需在流水線(xiàn)的入口發(fā)出請(qǐng)求即可，請(qǐng)求自動(dòng)在流水線(xiàn)上傳遞，直到被處理。

該模式將接收對(duì)象鏈接在一起，然后將任何請(qǐng)求消息從對(duì)象傳遞到對(duì)象，直到它到達(dá)能夠處理消息的對(duì)象。

處理程序?qū)ο蟮臄?shù)量和類(lèi)型事先是未知的，它們可以動(dòng)態(tài)配置。

處理器對(duì)象的數(shù)據(jù)和類(lèi)型事先都不確定，需要?jiǎng)討B(tài)配置

鏈接機(jī)制使用遞歸組合來(lái)允許無(wú)限數(shù)量的處理程序進(jìn)行鏈接。

使用遞歸組合的方式，將多個(gè)處理程序連成“職責(zé)鏈”
責(zé)任鏈簡(jiǎn)化了對(duì)象互連。

發(fā)件人和收件人不是保留對(duì)所有候選收件人的引用，而是每個(gè)發(fā)件人對(duì)鏈的頭部保持一個(gè)單一的引用，并且每個(gè)收件人對(duì)鏈中的其直接后繼者保持單一引用。

請(qǐng)求的發(fā)起者無(wú)需維護(hù)所有可能的處理程序?qū)ο?，只需記錄職?zé)鏈的入口;每個(gè)處理程序只需要維護(hù)“下一個(gè)”處理程序即可，從而簡(jiǎn)化了各個(gè)處理程序之間的連接關(guān)系。

訪(fǎng)客與責(zé)任鏈

不是像傳統(tǒng)類(lèi)設(shè)計(jì)中將操作與數(shù)據(jù)捆綁在一起形成ADT，這兩個(gè)設(shè)計(jì)模式都是將“數(shù)據(jù)”與“作用于數(shù)據(jù)上的客戶(hù)端定制操作”分離開(kāi)來(lái)
原因：操作可以靈活增加，運(yùn)行時(shí)使用的操作可以動(dòng)態(tài)配置，多個(gè)操作的執(zhí)行次序可以動(dòng)態(tài)變化

區(qū)別1：visitor只定義了一個(gè)操作，chain of responsibility定義了一組操作及其之間的次序
區(qū)別2：訪(fǎng)客中，客戶(hù)創(chuàng)建訪(fǎng)客之后傳入ADT，ADT再將執(zhí)行權(quán)委托到visitor;責(zé)任鏈中，控制權(quán)完全在各個(gè)處理程序之間流轉(zhuǎn)，ADT（請(qǐng)求對(duì)象）完全感受不到。

文本：“獨(dú)立于制造商”，“獨(dú)立于設(shè)備”，“必須支持一系列產(chǎn)品”
=>抽象工廠(chǎng)模式
文本：“必須與現(xiàn)有對(duì)象接口”
=>適配器模式
文本：“必須與多個(gè)系統(tǒng)接口，其中一些系統(tǒng)將在未來(lái)開(kāi)發(fā)”，“必須展示早期的原型”
=>橋模式
文本：“必須與現(xiàn)有的一組對(duì)象接口”
=>外墻模式

文本：“復(fù)雜結(jié)構(gòu)”，“必須具有可變的深度和寬度”
=>復(fù)合模式
文本：“必須是位置透明的”
=>代理模式
文本：“必須可擴(kuò)展”，“必須可擴(kuò)展”
=>觀(guān)察者模式
文本：“必須提供獨(dú)立于該機(jī)制的政策”
=>策略模式

組合，適配器，橋接，包裝，代理（結(jié)構(gòu)模式）

重點(diǎn)：組成物體形成更大的結(jié)構(gòu)
?從舊功能中實(shí)現(xiàn)新功能，
?提供靈活性和可擴(kuò)展性

命令，觀(guān)察者，策略，模板（行為模式）

重點(diǎn)：算法和對(duì)象的責(zé)任分配
?避免與特定解決方案緊密耦合

抽象工廠(chǎng)，生成器（創(chuàng)造性模式）

重點(diǎn)：創(chuàng)建復(fù)雜的對(duì)象
?隱藏復(fù)雜對(duì)象的創(chuàng)建和組合

創(chuàng)造性模式

工廠(chǎng)方法，抽象工廠(chǎng)，Builder

結(jié)構(gòu)模式

橋接，代理，復(fù)合

行為模式

中介，觀(guān)察員，訪(fǎng)問(wèn)者，責(zé)任鏈，命令

對(duì)可重用性和可維護(hù)性設(shè)計(jì)模式的高層考慮