設(shè)計模式精解-GOF23種設(shè)計模式解析 重寫實現(xiàn)包含

1、設(shè)計模式筆記（C+）一、創(chuàng)建型Factory：工廠1、定義創(chuàng)建對象的接口，封裝了對象的創(chuàng)建2、使得具體化類的工作延遲到了子類中3、Factory模式正如我在相應(yīng)的文檔中分析的是為一類對象提供創(chuàng)建接口或者延遲對象的創(chuàng)建到子類中實現(xiàn)。AbstractFactory：抽象工廠1、創(chuàng)建一組相關(guān)或者相互依賴的對象2、AbstractFactory模式是為創(chuàng)建一組（有多類）相關(guān)或者依賴的對象提供創(chuàng)建接口3、AbstractFactory模式通常都是使用Factory模式實現(xiàn)（ConcreateFactroy）Singleton：單例1、Singleton模式保證一個類僅有一個對象，并提供一個訪問它的全局訪

2、問點。2、全局變量不能防止實例化多個對象。3、全局變量將使得對象在無論是否用到都要被創(chuàng)建。Builder：創(chuàng)建者1、Builder模式的意圖是非常容易理解、間接的：將一個復(fù)雜對象的構(gòu)建與它的表示分離，使用同樣的構(gòu)建過程可以創(chuàng)建不同的表示（在示例代碼中可以通過傳入不同的參數(shù)實現(xiàn)這一點）。Builder模式和AbstractFactory模式在功能上很相似，因為都是創(chuàng)建大的復(fù)雜的對象，它們的區(qū)別是：Builder模式強調(diào)的是一步步創(chuàng)建對象，并通過相同的創(chuàng)建過程可以獲得不同的結(jié)果對象，一般來說Builder模式中對象不是直接返回的。而在AbstractFactory模式中對象是直接返回的，Abstr

3、actFactory模式強調(diào)的是為創(chuàng)建多個相互依賴的對象提供一個同一的接口。Prototype：原型1、Prototype模式通過復(fù)制原型（Prototype）而獲得新對象創(chuàng)建的功能，這里Prototype本身就是“對象工廠”（因為能夠生產(chǎn)對象），實際上Prototype模式和Builder模式、AbstractFactory模式都是通過一個類（對象實例）來專門負責對象的創(chuàng)建工作（工廠對象），它們之間的區(qū)別是：Builder模式重在復(fù)雜對象的一步步創(chuàng)建（并不直接返回對象），AbstractFactory模式重在產(chǎn)生多個相互依賴的對象，而Prototype模式重在從自身復(fù)制自己創(chuàng)建新類。二、結(jié)構(gòu)

4、型Bridge：橋梁1、Bridge模式將抽象和實現(xiàn)分別獨立實現(xiàn)2、Bridge中設(shè)計模式中比較復(fù)雜和難理解的模式之一，也是OO開發(fā)與設(shè)計中經(jīng)常會用到的模式之一。使用組合（委托）的方式將抽象和實現(xiàn)徹底地解耦，這樣的好處是抽象和實現(xiàn)可以分別獨立地變化，系統(tǒng)的耦合性也得到了很好的降低。3、使用Bridge模式和使用帶來問題方式的解決方案的根本區(qū)別在于是通過繼承還是通過組合的方式去實現(xiàn)一個功能需求。Adapter：適配器1、Adapter模式的兩種類別：類模式和對象模式2、類模式Adapter中，我們通過private繼承Adaptee獲得實現(xiàn)繼承的效果，而通過public繼承Target獲得接口繼

5、承的效果。3、在Adapter模式的兩種模式中，有一個很重要的概念就是接口繼承和實現(xiàn)繼承的區(qū)別和聯(lián)系。接口繼承和實現(xiàn)繼承是面向?qū)ο箢I(lǐng)域的兩個重要的概念，接口繼承指的是通過繼承，子類獲得了父類的接口，而實現(xiàn)繼承指的是通過繼承子類獲得父順的實現(xiàn)（并不統(tǒng)共接口）Decorator：裝飾者1、Decorator提供了一種給類增加職責的方法，不是通過繼承實現(xiàn)，而是通過組合。2、Decorator模式除了采用組合的方式取得了比采用繼承方式更好的效果，Decorator模式還給設(shè)計帶來一種“即用即付”的方式來添加職責。Composite：組成、樹1、遞歸構(gòu)建樹狀的組合結(jié)構(gòu)2、Composite模式通過和De

6、corator模式有著類似的結(jié)構(gòu)圖，但是Composite模式旨在構(gòu)造類，而Decorator模式重在不生成子類即可給對象添加職責。Decorator模式重在修飾，而Composite模式重在表示。Flyweight：享元1、2、Flyweight模式中有一個類似Factory模式的對象構(gòu)造工廠FlyweightFactory，當客戶程序員（Client）需要一個對象的時候就會向FlayweigthFactory發(fā)出請求對象的消息GetFlyweigth（）消息，F(xiàn)lyweightFactory擁有一個管理、存儲對象的“倉庫”（或者叫對象池，vector實現(xiàn)），GetFlyweight（）消息

7、會遍歷對象池中的對象，如果已經(jīng)存在則直接返回給Client，否則創(chuàng)建一個新的對象返回給Client。當然可能也有不想被共享的對象（例如結(jié)構(gòu)圖中的UnshareConcreateFlyweight），但不在本模式的講解范圍，故在實現(xiàn)中不給出。Facade：外觀1、2、Facade模式在高層提供了一個統(tǒng)一的接口，解耦了系統(tǒng)。設(shè)計模式中還有另一種模式Mediator也和Facade有類似的地方。但是Mediator主要目的是對象間的訪問的解耦。Proxy：代理1、Proxy模式最大的好處就是實現(xiàn)了邏輯和實現(xiàn)的徹底解耦。2、虛代理（Virtual Proxy）3、遠程代理（Remoto Proxy）4

8、、保護代理（Protection Proxy）5、智能指針（Smart Pointer）三、行為Template：模板1、對于某一個業(yè)務(wù)邏輯（算法實現(xiàn)）在不同的對象中有不同的細節(jié)實現(xiàn)，但是邏輯（算法）的框架（或通用的應(yīng)用算法）是相同的。Template提供了這種情況的一個實現(xiàn)框架。2、Template模式是采用繼承的方式實現(xiàn)這一點：將邏輯（算法）框架放在抽象基類中，并定義好細節(jié)接口，子類中細節(jié)。3、Strategy（ 策略 ）模式解決的是和Template模式類似的問題，但是Strategy模式是將邏輯（算法）封裝到一個類中，并采取組合（委托）的方式解決這個問題。4、Template模式是很簡

9、單模式，但是也應(yīng)用很廣的模式。如上面的分析稆實現(xiàn)中闡明的Template是采用繼承方式實現(xiàn)算法的異構(gòu)，其關(guān)鍵點就是通用算法封裝在抽象基類中，并將不同的算法細節(jié)放到子類中實現(xiàn)。Template模式獲得一種反向控制結(jié)構(gòu)效果，這也是面向?qū)ο笙到y(tǒng)的分析和設(shè)計中一個原則DIP（依賴倒置：Dependency Inversion Principles）。其含義就是父類調(diào)用子類的操作（高層模塊調(diào)用低層模塊的操作），低層模塊實現(xiàn)高層模塊聲明的接口。這樣控制權(quán)在父類（高層模塊），低層模塊反而要依賴高層模塊。Template模式實際上就是利用面向?qū)ο笾卸鄳B(tài)的概念實現(xiàn)算法實現(xiàn)細節(jié)和高層的接口的松耦合?？梢钥吹絋em

10、plate模式采取的是繼承方式實現(xiàn)這一點的，由于繼承是一種強制約束性的條件，因此也給Template模式帶來一些許多不方便的地方。Strategy：策略1、Strategy模式和Template模式要解決的問題是相同（類似）的，都是為了給業(yè)務(wù)邏輯（算法）具體實現(xiàn)和抽象接口之間的解耦。Strategy模式將邏輯（算法）封裝到一個類（Context）里面，通過的方式將具體算法的實現(xiàn)在組合對象中實現(xiàn)，再通過委托的方式將抽象接口的實現(xiàn)委托給組合對象實現(xiàn)。State模式也有類似的功能。2、Strategy模式和Template模式實際是實現(xiàn)一個抽象接口的兩種方式：繼承和組合之間的區(qū)別。3、繼承：優(yōu)點：（

11、1）易于修改和擴展那些被利用的實現(xiàn)缺點：（1）破壞了封裝性，繼承中父類的實現(xiàn)細節(jié)暴露給子類了（2）“白盒”復(fù)用（3）當父類的實現(xiàn)更改時，其所有子類將不得不隨之改變（4）從父類繼承而來的實現(xiàn)在運行期間不能改變（編譯期間就已經(jīng)確定了）4、組合優(yōu)點：（1）“黑盒”復(fù)用，因為被包含對象的內(nèi)部細節(jié)對外是不可見的（2）封裝性好（3）實現(xiàn)和抽象的依賴性很?。ńM合對象和被組合對象之間的依賴性?。?）可以在運行其它動態(tài)定義實現(xiàn)（通過一個指向相同類型的指針，典型的是抽象類的指針）缺點：（1）系統(tǒng)中對象過多5、面向?qū)ο蟮脑O(shè)計中的有一條很重要的原則就是：優(yōu)先使用（對象）組合，而非（類）繼承（Favor Compos

12、ition Over Inheritance）6、Strategy模式和State模式也有相似之處，但是State模式注重的對象在不同的狀態(tài)下不同的操作。兩者之間的區(qū)別就是State模式中具體實現(xiàn)類中有一個指向Context的引用，而Strategy模式則沒有。State：狀態(tài)1、將State聲明為Context的友元類（Friend Class），其作用是讓State模式訪問Context的protected接口ChangeState（）2、State及其子類中的操作都將Context*傳入作為參數(shù)，其主要目的是State類可以通過這個指針調(diào)用Context中的方法（在本示例代碼中沒有體現(xiàn)）

13、。這也是State模式和Strategy模式的最大區(qū)別所在。3、State和Strategy相同：它們都有一個Context類，都是通過委托（組合）給一個具有多個派生類的多態(tài)基類實現(xiàn)Context的算法邏輯。區(qū)別：State模式中派生類持有指向Context對象的引用，并通過這個引用調(diào)用Context中的方法，但在Strategy模式中就沒有這種情況。因此可以說一個State實例同樣是Strategy模式的一個實例，反之卻不成立。State模式主要是要適應(yīng)對象對于狀態(tài)改變時的不同處理策略的實現(xiàn)，而Strategy則主要是具體算法和實現(xiàn)接口的解耦（coupling），Strategy模式中并沒有

14、狀態(tài)的概念（雖然很多時候有可以看作是狀態(tài)的概念），并且更加不關(guān)心狀態(tài)的改變。Observer：觀察者1、Observer模式應(yīng)該可以說是應(yīng)用最多、影響最廣的模式之一，因為Observer的一個實例Model/View、Control（MVC）結(jié)構(gòu)在系統(tǒng)開發(fā)架構(gòu)設(shè)計中有著很重要的地位和意義，MVC實現(xiàn)了業(yè)務(wù)邏輯和表示層的解耦。個人也認為Observer模式是軟件開發(fā)過程中必須要掌握和使用的模式之一。2、Observer模式要解決的問題為：建立一個一（Subject）對多（Observer）的依賴關(guān)系，并且做到當“一”變化的時候，依賴這個“一”的多也能夠同步改變。Memento：備忘1、Memen

15、to模式的關(guān)鍵就是在不破壞封裝的前提下，捕獲并保存一個類的內(nèi)部狀態(tài)，這樣就可以利用保存的狀態(tài)實施恢復(fù)操作。2、Mediator：中介者1、Mediator模式提供將對象間的交互和通訊封裝在一個類中，各個對象間的通信不必顯式去聲明和引用，大大降低了系統(tǒng)的復(fù)雜性能。2、Mediator模式還帶來了系統(tǒng)對象間的松耦合Command：命令1、Command模式通過將請求封裝到一個對象（Command）中，并將請求的接受者存放到具體的ConcreateCommand類中（Receiver）中，從而實現(xiàn)調(diào)用操作的對象和操作的具體實現(xiàn)者之間的解耦。2、模板類的構(gòu)造函數(shù)必須要實現(xiàn)，要不編譯通過，連接不上，錯誤

16、提示也不準確（模板類的函數(shù)指針）Command模式結(jié)構(gòu)中，將請求的接收者（處理者）放到Command的具體子類ConcreateCommand中，當請求到來時（Invoker發(fā)出Invoke消息激活Command對象），ConcreateCommand將處理請求交給Receiver對象進行處理。Visitor：訪問者1、Visitor模式則提供了一個解決方案：將更新（變更）封裝到一個類中（訪問操作），并由待更改類提供一個接收接口，則可達到效果。2、Visitor模式在不破壞類的前提下，為類提供增加新的操作。Visitor模式的關(guān)鍵是雙分派（Double-Dispatch）的技術(shù)。（雙分派意味著

17、執(zhí)行的操作將取決于請求的種類和接收者的類型）在Visitor模式中Accept()操作是一個雙分派的操作。具體調(diào)用哪一個具體的Accept()操作，有兩個決定因素：（1）Element的類型。因為Accept()是多態(tài)的操作，需要具體的Element類型的子類才可以決定到底調(diào)用哪一個Accept()實現(xiàn)。（2）Visitor類型。Accept()操作有一個參數(shù)（Visitor* vis），要決定了實際傳進來的Visitor的實際類別才可以決定具體是調(diào)用哪個VisitorConcrete()實現(xiàn)。3、問題（1）破壞了封裝性（2）ConcreateElement的擴展很困難Chain of Responsibility：責任鏈1、Chain of Responsibility模式描述其實就是這樣一類問題將可能處理一個請求的對象鏈接成一個鏈，并將請求在這個鏈上傳遞，直到有對象處理該請求（可能需要提供一個默認處理所有請求的類）2、Chain of Responsibility模式最大的一個優(yōu)點就是給系統(tǒng)降低了