最新設(shè)計(jì)模式精解GOF23種設(shè)計(jì)模式解析VS202重寫實(shí)現(xiàn)包含LinuxMakefile代碼和原文檔已插入本文檔 免費(fèi)下載.doc

設(shè)計(jì)模式筆記（C+）一、創(chuàng)建型Factory：工廠1、定義創(chuàng)建對象的接口，封裝了對象的創(chuàng)建2、使得具體化類的工作延遲到了子類中3、Factory模式正如我在相應(yīng)的文檔中分析的是為一類對象提供創(chuàng)建接口或者延遲對象的創(chuàng)建到子類中實(shí)現(xiàn)。AbstractFactory：抽象工廠1、創(chuàng)建一組相關(guān)或者相互依賴的對象2、AbstractFactory模式是為創(chuàng)建一組（有多類）相關(guān)或者依賴的對象提供創(chuàng)建接口3、AbstractFactory模式通常都是使用Factory模式實(shí)現(xiàn)（ConcreateFactroy）Singleton：單例1、Singleton模式保證一個(gè)類僅有一個(gè)對象，并提供一個(gè)訪問它的全局訪問點(diǎn)。2、全局變量不能防止實(shí)例化多個(gè)對象。3、全局變量將使得對象在無論是否用到都要被創(chuàng)建。Builder：創(chuàng)建者1、Builder模式的意圖是非常容易理解、間接的：將一個(gè)復(fù)雜對象的構(gòu)建與它的表示分離，使用同樣的構(gòu)建過程可以創(chuàng)建不同的表示（在示例代碼中可以通過傳入不同的參數(shù)實(shí)現(xiàn)這一點(diǎn)）。Builder模式和AbstractFactory模式在功能上很相似，因?yàn)槎际莿?chuàng)建大的復(fù)雜的對象，它們的區(qū)別是：Builder模式強(qiáng)調(diào)的是一步步創(chuàng)建對象，并通過相同的創(chuàng)建過程可以獲得不同的結(jié)果對象，一般來說Builder模式中對象不是直接返回的。而在AbstractFactory模式中對象是直接返回的，AbstractFactory模式強(qiáng)調(diào)的是為創(chuàng)建多個(gè)相互依賴的對象提供一個(gè)同一的接口。Prototype：原型1、Prototype模式通過復(fù)制原型（Prototype）而獲得新對象創(chuàng)建的功能，這里Prototype本身就是“對象工廠”（因?yàn)槟軌蛏a(chǎn)對象），實(shí)際上Prototype模式和Builder模式、AbstractFactory模式都是通過一個(gè)類（對象實(shí)例）來專門負(fù)責(zé)對象的創(chuàng)建工作（工廠對象），它們之間的區(qū)別是：Builder模式重在復(fù)雜對象的一步步創(chuàng)建（并不直接返回對象），AbstractFactory模式重在產(chǎn)生多個(gè)相互依賴的對象，而Prototype模式重在從自身復(fù)制自己創(chuàng)建新類。二、結(jié)構(gòu)型Bridge：橋梁1、Bridge模式將抽象和實(shí)現(xiàn)分別獨(dú)立實(shí)現(xiàn)2、Bridge中設(shè)計(jì)模式中比較復(fù)雜和難理解的模式之一，也是OO開發(fā)與設(shè)計(jì)中經(jīng)常會(huì)用到的模式之一。使用組合（委托）的方式將抽象和實(shí)現(xiàn)徹底地解耦，這樣的好處是抽象和實(shí)現(xiàn)可以分別獨(dú)立地變化，系統(tǒng)的耦合性也得到了很好的降低。3、使用Bridge模式和使用帶來問題方式的解決方案的根本區(qū)別在于是通過繼承還是通過組合的方式去實(shí)現(xiàn)一個(gè)功能需求。Adapter：適配器1、Adapter模式的兩種類別：類模式和對象模式2、類模式Adapter中，我們通過private繼承Adaptee獲得實(shí)現(xiàn)繼承的效果，而通過public繼承Target獲得接口繼承的效果。3、在Adapter模式的兩種模式中，有一個(gè)很重要的概念就是接口繼承和實(shí)現(xiàn)繼承的區(qū)別和聯(lián)系。接口繼承和實(shí)現(xiàn)繼承是面向?qū)ο箢I(lǐng)域的兩個(gè)重要的概念，接口繼承指的是通過繼承，子類獲得了父類的接口，而實(shí)現(xiàn)繼承指的是通過繼承子類獲得父順的實(shí)現(xiàn)（并不統(tǒng)共接口）Decorator：裝飾者1、Decorator提供了一種給類增加職責(zé)的方法，不是通過繼承實(shí)現(xiàn)，而是通過組合。2、Decorator模式除了采用組合的方式取得了比采用繼承方式更好的效果，Decorator模式還給設(shè)計(jì)帶來一種“即用即付”的方式來添加職責(zé)。Composite：組成、樹1、遞歸構(gòu)建樹狀的組合結(jié)構(gòu)2、Composite模式通過和Decorator模式有著類似的結(jié)構(gòu)圖，但是Composite模式旨在構(gòu)造類，而Decorator模式重在不生成子類即可給對象添加職責(zé)。Decorator模式重在修飾，而Composite模式重在表示。Flyweight：享元1、2、Flyweight模式中有一個(gè)類似Factory模式的對象構(gòu)造工廠FlyweightFactory，當(dāng)客戶程序員（Client）需要一個(gè)對象的時(shí)候就會(huì)向FlayweigthFactory發(fā)出請求對象的消息GetFlyweigth（）消息，F(xiàn)lyweightFactory擁有一個(gè)管理、存儲(chǔ)對象的“倉庫”（或者叫對象池，vector實(shí)現(xiàn)），GetFlyweight（）消息會(huì)遍歷對象池中的對象，如果已經(jīng)存在則直接返回給Client，否則創(chuàng)建一個(gè)新的對象返回給Client。當(dāng)然可能也有不想被共享的對象（例如結(jié)構(gòu)圖中的UnshareConcreateFlyweight），但不在本模式的講解范圍，故在實(shí)現(xiàn)中不給出。Facade：外觀1、2、Facade模式在高層提供了一個(gè)統(tǒng)一的接口，解耦了系統(tǒng)。設(shè)計(jì)模式中還有另一種模式Mediator也和Facade有類似的地方。但是Mediator主要目的是對象間的訪問的解耦。Proxy：代理1、Proxy模式最大的好處就是實(shí)現(xiàn)了邏輯和實(shí)現(xiàn)的徹底解耦。2、虛代理（Virtual Proxy）3、遠(yuǎn)程代理（Remoto Proxy）4、保護(hù)代理（Protection Proxy）5、智能指針（Smart Pointer）三、行為Template：模板1、對于某一個(gè)業(yè)務(wù)邏輯（算法實(shí)現(xiàn)）在不同的對象中有不同的細(xì)節(jié)實(shí)現(xiàn)，但是邏輯（算法）的框架（或通用的應(yīng)用算法）是相同的。Template提供了這種情況的一個(gè)實(shí)現(xiàn)框架。2、Template模式是采用繼承的方式實(shí)現(xiàn)這一點(diǎn)：將邏輯（算法）框架放在抽象基類中，并定義好細(xì)節(jié)接口，子類中細(xì)節(jié)。3、Strategy（ 策略 ）模式解決的是和Template模式類似的問題，但是Strategy模式是將邏輯（算法）封裝到一個(gè)類中，并采取組合（委托）的方式解決這個(gè)問題。4、Template模式是很簡單模式，但是也應(yīng)用很廣的模式。如上面的分析稆實(shí)現(xiàn)中闡明的Template是采用繼承方式實(shí)現(xiàn)算法的異構(gòu)，其關(guān)鍵點(diǎn)就是通用算法封裝在抽象基類中，并將不同的算法細(xì)節(jié)放到子類中實(shí)現(xiàn)。Template模式獲得一種反向控制結(jié)構(gòu)效果，這也是面向?qū)ο笙到y(tǒng)的分析和設(shè)計(jì)中一個(gè)原則DIP（依賴倒置：Dependency Inversion Principles）。其含義就是父類調(diào)用子類的操作（高層模塊調(diào)用低層模塊的操作），低層模塊實(shí)現(xiàn)高層模塊聲明的接口。這樣控制權(quán)在父類（高層模塊），低層模塊反而要依賴高層模塊。Template模式實(shí)際上就是利用面向?qū)ο笾卸鄳B(tài)的概念實(shí)現(xiàn)算法實(shí)現(xiàn)細(xì)節(jié)和高層的接口的松耦合。可以看到Template模式采取的是繼承方式實(shí)現(xiàn)這一點(diǎn)的，由于繼承是一種強(qiáng)制約束性的條件，因此也給Template模式帶來一些許多不方便的地方。Strategy：策略1、Strategy模式和Template模式要解決的問題是相同（類似）的，都是為了給業(yè)務(wù)邏輯（算法）具體實(shí)現(xiàn)和抽象接口之間的解耦。Strategy模式將邏輯（算法）封裝到一個(gè)類（Context）里面，通過的方式將具體算法的實(shí)現(xiàn)在組合對象中實(shí)現(xiàn)，再通過委托的方式將抽象接口的實(shí)現(xiàn)委托給組合對象實(shí)現(xiàn)。State模式也有類似的功能。2、Strategy模式和Template模式實(shí)際是實(shí)現(xiàn)一個(gè)抽象接口的兩種方式：繼承和組合之間的區(qū)別。3、繼承：優(yōu)點(diǎn)：（1）易于修改和擴(kuò)展那些被利用的實(shí)現(xiàn)缺點(diǎn)：（1）破壞了封裝性，繼承中父類的實(shí)現(xiàn)細(xì)節(jié)暴露給子類了（2）“白盒”復(fù)用（3）當(dāng)父類的實(shí)現(xiàn)更改時(shí)，其所有子類將不得不隨之改變（4）從父類繼承而來的實(shí)現(xiàn)在運(yùn)行期間不能改變（編譯期間就已經(jīng)確定了）4、組合優(yōu)點(diǎn)：（1）“黑盒”復(fù)用，因?yàn)楸话瑢ο蟮膬?nèi)部細(xì)節(jié)對外是不可見的（2）封裝性好（3）實(shí)現(xiàn)和抽象的依賴性很小（組合對象和被組合對象之間的依賴性?。?）可以在運(yùn)行其它動(dòng)態(tài)定義實(shí)現(xiàn)（通過一個(gè)指向相同類型的指針，典型的是抽象類的指針）缺點(diǎn)：（1）系統(tǒng)中對象過多5、面向?qū)ο蟮脑O(shè)計(jì)中的有一條很重要的原則就是：優(yōu)先使用（對象）組合，而非（類）繼承（Favor Composition Over Inheritance）6、Strategy模式和State模式也有相似之處，但是State模式注重的對象在不同的狀態(tài)下不同的操作。兩者之間的區(qū)別就是State模式中具體實(shí)現(xiàn)類中有一個(gè)指向Context的引用，而Strategy模式則沒有。State：狀態(tài)1、將State聲明為Context的友元類（Friend Class），其作用是讓State模式訪問Context的protected接口ChangeState（）2、State及其子類中的操作都將Context*傳入作為參數(shù)，其主要目的是State類可以通過這個(gè)指針調(diào)用Context中的方法（在本示例代碼中沒有體現(xiàn)）。這也是State模式和Strategy模式的最大區(qū)別所在。3、State和Strategy相同：它們都有一個(gè)Context類，都是通過委托（組合）給一個(gè)具有多個(gè)派生類的多態(tài)基類實(shí)現(xiàn)Context的算法邏輯。區(qū)別：State模式中派生類持有指向Context對象的引用，并通過這個(gè)引用調(diào)用Context中的方法，但在Strategy模式中就沒有這種情況。因此可以說一個(gè)State實(shí)例同樣是Strategy模式的一個(gè)實(shí)例，反之卻不成立。State模式主要是要適應(yīng)對象對于狀態(tài)改變時(shí)的不同處理策略的實(shí)現(xiàn)，而Strategy則主要是具體算法和實(shí)現(xiàn)接口的解耦（coupling），Strategy模式中并沒有狀態(tài)的概念（雖然很多時(shí)候有可以看作是狀態(tài)的概念），并且更加不關(guān)心狀態(tài)的改變。Observer：觀察者1、Observer模式應(yīng)該可以說是應(yīng)用最多、影響最廣的模式之一，因?yàn)镺bserver的一個(gè)實(shí)例Model/View、Control（MVC）結(jié)構(gòu)在系統(tǒng)開發(fā)架構(gòu)設(shè)計(jì)中有著很重要的地位和意義，MVC實(shí)現(xiàn)了業(yè)務(wù)邏輯和表示層的解耦。個(gè)人也認(rèn)為Observer模式是軟件開發(fā)過程中必須要掌握和使用的模式之一。2、Observer模式要解決的問題為：建立一個(gè)一（Subject）對多（Observer）的依賴關(guān)系，并且做到當(dāng)“一”變化的時(shí)候，依賴這個(gè)“一”的多也能夠同步改變。Memento：備忘1、Memento模式的關(guān)鍵就是在不破壞封裝的前提下，捕獲并保存一個(gè)類的內(nèi)部狀態(tài)，這樣就可以利用保存的狀態(tài)實(shí)施恢復(fù)操作。2、Mediator：中介者1、Mediator模式提供將對象間的交互和通訊封裝在一個(gè)類中，各個(gè)對象間的通信不必顯式去聲明和引用，大大降低了系統(tǒng)的復(fù)雜性能。2、Mediator模式還帶來了系統(tǒng)對象間的松耦合Command：命令1、Command模式通過將請求封裝到一個(gè)對象（Command）中，并將請求的接受者存放到具體的ConcreateCommand類中（Receiver）中，從而實(shí)現(xiàn)調(diào)用操作的對象和操作的具體實(shí)現(xiàn)者之間的解耦。2、模板類的構(gòu)造函數(shù)必須要實(shí)現(xiàn)，要不編譯通過，連接不上，錯(cuò)誤提示也不準(zhǔn)確（模板類的函數(shù)指針）Command模式結(jié)構(gòu)中，將請求的接收者（處理者）放到Command的具體子類ConcreateCommand中，當(dāng)請求到來時(shí)（Invoker發(fā)出Invoke消息激活Command對象），ConcreateCommand將處理請求交給Receiver對象進(jìn)行處理。Visitor：訪問者1、Visitor模式則提供了一個(gè)解決方案：將更新（變更）封裝到一個(gè)類中（訪問操作），并由待更改類提供一個(gè)接收接口，則可達(dá)到效果。2、Visitor模式在不破壞類的前提下，為類提供增加新的操作。Visitor模式的關(guān)鍵是雙分派（Double-Dispatch）的技術(shù)。（雙分派意味著執(zhí)行的操作將取決于請求的種類和接收者的類型）在Visitor模式中Accept()操作是一個(gè)雙分派的操作。具體調(diào)用哪一個(gè)具體的Accept()操作，有兩個(gè)決定因素：（1）Element的類型。因?yàn)锳ccept()是多態(tài)的操作，需要具體的Element類型的子類才可以決定到底調(diào)用哪一個(gè)Accept()實(shí)現(xiàn)。（2）Visitor類型。Accept()操作有一個(gè)參數(shù)（Visitor* vis），要決定了實(shí)際傳進(jìn)來的Visitor的實(shí)際類別才可以決定具體是調(diào)用哪個(gè)VisitorConcrete()實(shí)現(xiàn)。3、問題（1）破壞了封裝性（2）ConcreateElement的擴(kuò)展很困難Chain of Responsibility：責(zé)任鏈1、Chain of Responsibility模式描述其實(shí)就是這樣一類問題將可能處理一個(gè)請求的對象鏈接成一個(gè)鏈，并將請求在這個(gè)鏈上傳遞，直到有對象處理該請求（可能需要提供一個(gè)默認(rèn)處理所有請求的類）2、Chain of Responsibility模式最大的一個(gè)優(yōu)點(diǎn)就是給系統(tǒng)降低了