從2005年初聽(tīng)說(shuō)設(shè)計(jì)模式，到現(xiàn)在雖然已經(jīng)8年多了，但GoF的23種模式依然盛行，當(dāng)然GoF提出這些模式的年代更加久遠(yuǎn)（1995年）。

　　在工作的過(guò)程中，陸陸續(xù)續(xù)接觸了GoF的大部分模式，我記得在2008年的時(shí)候就想總結(jié)一 下設(shè)計(jì)模式（最近想做的兩件事情），最后因?yàn)楦鞣N原因也沒(méi)有完成。最近這段時(shí)間正好是職業(yè)空檔期，沒(méi)什么事兒做，就把之前看過(guò)的設(shè)計(jì)模式翻出來(lái)整理了一 下，于是就有了上面幾篇文章。

　　整理設(shè)計(jì)模式的過(guò)程，也是一個(gè)深刻理解面向?qū)ο笤O(shè)計(jì)的過(guò)程。通過(guò)對(duì)各個(gè)模式的回顧，讓我更能夠明白前輩們關(guān)于面向?qū)ο笤O(shè)計(jì)提出的各種“最佳實(shí)踐”，特別是S.O.L.I.D，我覺(jué)得在這里再說(shuō)一次，也不算矯情。

　　S：?jiǎn)我宦氊?zé)原則（Single Responsibility Principle, SRP），一個(gè)類只能有一個(gè)原因使其發(fā)生改變，即一個(gè)類只承擔(dān)一個(gè)職責(zé)。

　　O：開(kāi)放-封閉原則（Open-Close Principle, OCP），這里指我們的設(shè)計(jì)應(yīng)該針對(duì)擴(kuò)展開(kāi)放，針對(duì)修改關(guān)閉，即盡量以擴(kuò)展的方式來(lái)維護(hù)系統(tǒng)。

　　L：里氏替換原則（Liskov Subsititution Principle, LSP），它表示我們可以在代碼中使用任意子類來(lái)替代父類并且程序不受影響，這樣可以保證我們使用“繼承”并沒(méi)有破壞父類。

　　I：接口隔離原則（Interface Segregation Principle, ISP），客戶端不應(yīng)該依賴于它不需要的接口，兩個(gè)類之間的依賴應(yīng)該建立在最小接口的基礎(chǔ)上。這條原則的目的是為了讓那些使用相同接口的類只需要實(shí)現(xiàn)特定必要的一組方法，而不是大量沒(méi)用的方法。

　　D：依賴倒置原則（Dependence Inversion Principle, DIP），高層模塊不應(yīng)該依賴于低層模塊，兩者應(yīng)該都依賴于抽象；抽象不依賴于細(xì)節(jié)，而細(xì)節(jié)應(yīng)該依賴于抽象。這里主要是提倡“面向接口”編程，而非“面向?qū)崿F(xiàn)”編程。

　　設(shè)計(jì)模式，從本質(zhì)上講，是針對(duì)過(guò)去某種經(jīng)驗(yàn)的總結(jié)。每種設(shè)計(jì)模式，都是為了在特定條件下去解決特定問(wèn)題，離開(kāi)這些前提去討論設(shè)計(jì)模式，是沒(méi)有意義的。

　　下面，我們快速回顧GoF的23種模式。

• 工廠方法
  意圖：定義一個(gè)用戶創(chuàng)建對(duì)象的接口，讓子類去決定具體使用哪個(gè)類。
  適用場(chǎng)合：1）類不知道它所要?jiǎng)?chuàng)建的對(duì)象的類信息；2）類希望由它的子類來(lái)創(chuàng)建對(duì)象。
• 抽象工廠
  意圖：提供一個(gè)創(chuàng)建一系列相關(guān)或者相互依賴的對(duì)象的接口，而無(wú)須指定它的具體實(shí)現(xiàn)類。
  適用場(chǎng)合：1）系統(tǒng)不依賴于產(chǎn)品是如何實(shí)現(xiàn)的細(xì)節(jié)；2）系統(tǒng)的產(chǎn)品族大于1，而在運(yùn)行時(shí)刻只需要某一種產(chǎn)品族；3）屬于同一個(gè)產(chǎn)品族的產(chǎn)品，必須綁在一起使用；4）所有的產(chǎn)品族，可以抽取公共接口
• 單例
  意圖：保證一個(gè)類只有一個(gè)實(shí)例，并且在系統(tǒng)全局范圍內(nèi)提供訪問(wèn)切入點(diǎn)。
  適用場(chǎng)合：各種“工廠類”
• 構(gòu)造者
  意圖：將復(fù)雜對(duì)象的構(gòu)造與表示相分離，使得同樣的構(gòu)造過(guò)程可以產(chǎn)生不同的復(fù)雜對(duì)象。
  適用場(chǎng)合：1）需要?jiǎng)?chuàng)建的對(duì)象有復(fù)雜的內(nèi)部結(jié)構(gòu)；2）對(duì)象的屬性之間相互依賴，創(chuàng)建時(shí)前后順序需要指定。
• 原型
  意圖：用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并通過(guò)復(fù)制原型實(shí)例得到對(duì)象。
  適用場(chǎng)合：1）系統(tǒng)不關(guān)心對(duì)象創(chuàng)建的細(xì)節(jié)；2）要實(shí)例化的對(duì)象的類型是動(dòng)態(tài)加載的；3）類在運(yùn)行過(guò)程中的狀態(tài)是有限的。
• 適配器
  意圖：將一個(gè)類的接口轉(zhuǎn)換成用戶希望的另一個(gè)接口。
  適用場(chǎng)合：系統(tǒng)需要使用現(xiàn)有類的功能，但接口不匹配
• 裝飾
  意圖：動(dòng)態(tài)的為對(duì)象添加額外職責(zé)
  適用場(chǎng)合：1）需要添加對(duì)象職責(zé)；2）這些職責(zé)可以動(dòng)態(tài)添加或者取消；3）添加的職責(zé)很多，從而不能用繼承實(shí)現(xiàn)。
• 橋接器
  意圖：將抽象部分與實(shí)現(xiàn)部分分離，從而使得它們可以獨(dú)立變化
  適用場(chǎng)合：1）系統(tǒng)需要在組件的抽象化角色與具體化角色之間增加更多的靈活；2）角色的任何變化都不應(yīng)該影響客戶端；3）組件有多個(gè)抽象化角色和具體化角色
• 享元
  意圖：運(yùn)用共享技術(shù)支持大量細(xì)粒度的對(duì)象
  適用場(chǎng)合：1）系統(tǒng)中有大量對(duì)象；2）這些對(duì)象占據(jù)大量?jī)?nèi)存；3）對(duì)象中的狀態(tài)可以很好的區(qū)分為外部和內(nèi)部；4）可以按照內(nèi)部狀態(tài)將對(duì)象分為不同的組；5）對(duì)系統(tǒng)來(lái)講，同一個(gè)組內(nèi)的對(duì)象是不可分辨的
• 門(mén)面
  意圖：為系統(tǒng)的一組接口提供一個(gè)一致的界面
  適用場(chǎng)合：1）為一個(gè)復(fù)雜的接口提供一個(gè)簡(jiǎn)單界面；2）保持不同子系統(tǒng)的獨(dú)立性；3）在分層設(shè)計(jì)中，定義每一層的入口
• 合成
  意圖：將對(duì)象組裝成樹(shù)狀結(jié)構(gòu)以表示“部分-整體”的關(guān)系
  適用場(chǎng)合：1）系統(tǒng)中的對(duì)象之間是“部分-整體”的關(guān)系；2）用戶不關(guān)心“部分”與“整體”之間的區(qū)別
• 代理
  意圖：為其他對(duì)象提供一種代理以控制對(duì)該對(duì)象的訪問(wèn)
  適用場(chǎng)合：對(duì)象無(wú)法直接訪問(wèn)（遠(yuǎn)程代理）
• 職責(zé)鏈
  意圖：對(duì)目標(biāo)對(duì)象實(shí)施一系列的操作，并且不希望調(diào)用雙方和操作之間有耦合關(guān)系
  適用場(chǎng)合：1）輸入對(duì)象需要經(jīng)過(guò)一系列處理；2）這些處理需要在運(yùn)行時(shí)指定；3）需要向多個(gè)操作發(fā)送處理請(qǐng)求；4）這些處理的順序是可變的
• 命令
  意圖：對(duì)一類對(duì)象公共操作的抽象
  適用場(chǎng)合：1）調(diào)用者同時(shí)和多個(gè)執(zhí)行對(duì)象交互；2）需要控制調(diào)用本身的生命周期；3）調(diào)用可以取消
• 觀察者
  意圖：定義對(duì)象之間一種“一對(duì)多”的關(guān)系，當(dāng)一個(gè)對(duì)象發(fā)生改變時(shí)，所有和它有依賴關(guān)系的對(duì)象都會(huì)得到通知
  適用場(chǎng)合：1）抽象模型有兩部分，其中一部分依賴于另一部分；2）一個(gè)對(duì)象的改變會(huì)導(dǎo)致其他很多對(duì)象發(fā)生改變；3）對(duì)象之間是松耦合
• 訪問(wèn)者
  意圖：對(duì)一組不同類型的元素進(jìn)行處理
  適用場(chǎng)合：1）一個(gè)類型需要依賴于多個(gè)不同接口的類型；2）需要經(jīng)常為一個(gè)結(jié)構(gòu)相對(duì)穩(wěn)定的對(duì)象添加新操作；3）需要用一個(gè)獨(dú)立的類型來(lái)組織一批不相干的操作，使用它的類型可以根據(jù)應(yīng)用需要進(jìn)行定制
• 模板
  意圖：定義一個(gè)操作步驟的方法骨架，而將其中一些細(xì)節(jié)的實(shí)現(xiàn)放到子類中
  適用場(chǎng)合：1）可以抽取方法骨架；2）控制子類的行為，只需要實(shí)現(xiàn)特定細(xì)節(jié)
• 策略
  意圖：對(duì)算法族進(jìn)行封裝
  適用場(chǎng)合：1）完成某項(xiàng)業(yè)務(wù)有多個(gè)算法；2）算法可提取公共接口
• 解釋器
  意圖：應(yīng)用或?qū)ο笈c用戶狡猾時(shí)，采取最具實(shí)效性的方式完成
  適用場(chǎng)合：1）針對(duì)對(duì)象的操作有規(guī)律可循；2）在執(zhí)行過(guò)程中，對(duì)效率要求不高，但對(duì)靈活性要求很高
• 迭代
  意圖：提供一種方法， 來(lái)順序訪問(wèn)集合中的所有元素
  適用場(chǎng)合：1）訪問(wèn)一個(gè)聚合對(duì)象的內(nèi)容，而不必暴露其內(nèi)部實(shí)現(xiàn)；2）支持對(duì)聚合對(duì)象的多種遍歷方式；3）為遍歷不同的聚合對(duì)象提供一致的接口
• 中介者
  意圖：避免大量對(duì)象之間的緊耦合
  適用場(chǎng)合：1）有大量對(duì)象彼此依賴（M：N）；2）某個(gè)類型要依賴于很多其他類型
• 備忘錄
  意圖：希望備份或者恢復(fù)復(fù)雜對(duì)象的部分屬性
  適用場(chǎng)合：1）對(duì)象的屬性比較多，但需要備份恢復(fù)的屬性比較少；2）對(duì)象的狀態(tài)是支持恢復(fù)的
• 狀態(tài)
  意圖：管理對(duì)象的多個(gè)狀態(tài)
  適用場(chǎng)合：1）對(duì)象的行為依賴于當(dāng)前狀態(tài)；2）業(yè)務(wù)處理過(guò)程存在多個(gè)分支，而且分支會(huì)越來(lái)越多

　　上面是對(duì)GoF23中模式的快速回顧，其中的理解未必很深刻很到位。對(duì)設(shè)計(jì)模式的學(xué)習(xí)是沒(méi)有止境的，而且它也只是面向?qū)ο蠓治雠c設(shè)計(jì)的冰山一偶

#p#

設(shè)計(jì)模式之創(chuàng)建型模式

　　GoF的設(shè)計(jì)模式一共23個(gè)，可以分為3大類：創(chuàng)建型、結(jié)構(gòu)型和行為型，這篇文章主要討論創(chuàng)建型。

　　創(chuàng)建型的設(shè)計(jì)模式包括：簡(jiǎn)單工廠（Simple Factory）、工廠方法（Factory Method）、抽象工廠（Abstract Factory）、單例（Singleton）、構(gòu)造者（Builder）和原型（Prototype），我們分別來(lái)討論。

　　我們首先來(lái)看工廠系列的3個(gè)設(shè)計(jì)模式，它們都主要是針對(duì)軟件設(shè)計(jì)中的“開(kāi)放-封閉”原則， 即程序應(yīng)該對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉。特別是當(dāng)我們的程序采用XML+反射的方式來(lái)創(chuàng)建對(duì)象時(shí)，工廠模式的威力就完全展現(xiàn)出來(lái)了，這時(shí)我們可以通過(guò)維護(hù)配置 文件的方式，來(lái)控制程序的邏輯。

　　1）簡(jiǎn)單工廠，當(dāng)我們的程序在實(shí)例化對(duì)象時(shí)，如果輸入條件不一樣，產(chǎn)生的對(duì)象也不一樣，那么我們可以考慮使用簡(jiǎn)單工廠對(duì)不同的實(shí)例進(jìn)行統(tǒng)一封裝， UML結(jié)構(gòu)如下：

　　優(yōu)點(diǎn)：封裝了具體對(duì)象的實(shí)例化過(guò)程，Client端和具體對(duì)象解耦，同時(shí)ProductManager可以作成靜態(tài)類或者Singleton對(duì)象，然后可以使用HashMap緩存具體對(duì)象（前提是對(duì)象沒(méi)有時(shí)間依賴性），降低創(chuàng)建對(duì)象的次數(shù)。

　　缺點(diǎn)：當(dāng)增添一種新類型的對(duì)象時(shí)，需要修改Productmanager的代碼（如果不采用XML）

　　2）工廠方法，它是針對(duì)簡(jiǎn)單工廠的改進(jìn)版，添加了對(duì)ProductManager的抽象，UML結(jié)構(gòu)如下：

　　優(yōu)點(diǎn)：結(jié)構(gòu)更加靈活，對(duì)于某種類型的對(duì)象來(lái)說(shuō)，會(huì)有一個(gè)特定的對(duì)象工廠指向它，這樣當(dāng)我們需要添加一種新類型的產(chǎn)品時(shí)，只需要添加兩個(gè)類，一個(gè)是具體產(chǎn)品類，一個(gè)是新產(chǎn)品的工廠類。這樣更加靈活。

　　缺點(diǎn)：結(jié)構(gòu)開(kāi)始變得復(fù)雜，而且最終還是需要Client端來(lái)確定究竟使用哪一個(gè)Factory（當(dāng)然這個(gè)信息可以保存在上下文或者配置文件中）。

　　3）抽象工廠，這個(gè)是最復(fù)雜的工廠模式，它用來(lái)生成一個(gè)產(chǎn)品線上的所有產(chǎn)品，我們假設(shè)一個(gè)產(chǎn)品線上包括多個(gè)產(chǎn)品，不同的產(chǎn)品線上的產(chǎn)品個(gè)數(shù)是一樣的，這樣我們需要一個(gè)針對(duì)產(chǎn)品線的抽象，并且很顯然不同產(chǎn)品線上的產(chǎn)品是不可能混到一起的。對(duì)應(yīng)的UML結(jié)構(gòu)圖如下：

　　上圖表明，一個(gè)產(chǎn)品線上的產(chǎn)品由IProduct1和IProduct2組成，客戶端在獲取產(chǎn)品時(shí)，這兩個(gè)產(chǎn)品應(yīng)該是同時(shí)返回的，因此對(duì)于IProductManager來(lái)說(shuō)，它需要同時(shí)生成這兩個(gè)對(duì)象。

　　優(yōu)點(diǎn)：對(duì)創(chuàng)建產(chǎn)品家族的行為高度抽象，添加一個(gè)產(chǎn)品線的邏輯比較清晰。

　　缺點(diǎn)：當(dāng)我們對(duì)產(chǎn)品線上的產(chǎn)品進(jìn)行增加和刪除時(shí)，對(duì)應(yīng)的操作比較麻煩，所有的產(chǎn)品工廠都需要進(jìn)行修改。

　　4）單例，這是比較好理解的一個(gè)模式，從字面上說(shuō)，就是程序在運(yùn)行的過(guò)程中，希望在任意時(shí)刻，都只保留某個(gè)對(duì)象的唯一實(shí)例。對(duì)應(yīng)的UML結(jié)構(gòu)圖如下：

　　單例的實(shí)現(xiàn)方式一般包括幾步：1）私有的指向自身的字段；2）私有構(gòu)造函數(shù)；3）公開(kāi)對(duì)私有字段進(jìn)行實(shí)例化的方法。也有幾種針對(duì)具體語(yǔ)言進(jìn)行的改善，例如針對(duì)多線程采用double lock機(jī)制，采用常量方式定義私有字段、使用內(nèi)嵌類來(lái)實(shí)例化字段等。

　　我們也可以對(duì)單例進(jìn)行一些適當(dāng)?shù)臄U(kuò)展，例如我們將對(duì)象的個(gè)數(shù)由1個(gè)變?yōu)镹個(gè)，這就成了對(duì)象池。

　　通常工廠模式中會(huì)使用到單例模式，特別是對(duì)于簡(jiǎn)單工廠來(lái)說(shuō)。

　　5）構(gòu)造者，對(duì)于一些復(fù)雜對(duì)象來(lái)說(shuō)，它可以分成多個(gè)不同的部分，在實(shí)例化時(shí)，不同部分之間實(shí)例化的順序，有時(shí)會(huì)有嚴(yán)格的限制，這時(shí)我們就可以使用構(gòu)造者模式了。對(duì)應(yīng)的UML結(jié)構(gòu)圖如下：

　　我們定義了IBuilder接口來(lái)實(shí)例化對(duì)應(yīng)的不同部分，同時(shí)有一個(gè)方法來(lái)返回對(duì)象的實(shí)例。而Constructor類的Construct方 法會(huì)按照業(yè)務(wù)邏輯依次調(diào)用實(shí)例化部分對(duì)象的方法，即BuildPartA、BuildPartB，這里的調(diào)用順序，完全由業(yè)務(wù)邏輯來(lái)控制，最后可以調(diào)用 GetProduct方法取得完整的對(duì)象實(shí)例。

　　我們有時(shí)也會(huì)對(duì)上圖進(jìn)行修改，例如將GetProduct放到Constructor中，或者將Construct方法放入到GetProduct（取消Constructor）中。即使有這些變形，但是基本的思想是不變的。

　　6）原型，我們?cè)诔绦蜻\(yùn)行過(guò)程中，當(dāng)需要有新的實(shí)例對(duì)象時(shí)，有時(shí)并不希望是從頭創(chuàng)建一個(gè)對(duì)象，而是希望新的實(shí)例的狀態(tài)和某個(gè)已存在的實(shí)例保持一致，這就是原型模式發(fā)揮作用的地方。對(duì)應(yīng)的UML結(jié)構(gòu)圖如下：

　　在.NET中，已經(jīng)定義了IClonable接口來(lái)實(shí)現(xiàn)原型模式。需要注意在實(shí)現(xiàn)時(shí)，會(huì)有深拷貝和淺拷貝的區(qū)別，深拷貝會(huì)同時(shí)拷貝堆棧和堆上的內(nèi)容，而淺拷貝只會(huì)拷貝堆棧上的內(nèi)容。

#p#

設(shè)計(jì)模式之結(jié)構(gòu)型模式

在 這部分里，我們關(guān)注GoF里面的結(jié)構(gòu)型模式，它主要是用于描述如何將類組合在一起去構(gòu)成更大的結(jié)構(gòu)。結(jié)構(gòu)型模式包括適配器（Adapter）、裝飾 （Decorator）、橋接器（Bridge）、享元（FlyWeight）、門(mén)面（Facade）、合成（Composite）以及代理 （Proxy）模式。

　　下面我們對(duì)上面提到的模式分別進(jìn)行描述。

　　1）適配器（Adapter）。當(dāng)我們已經(jīng)開(kāi)發(fā)出一個(gè)模塊，有一套清晰的接口，并且模塊正在被某個(gè)功能使用（意味著模塊接口改變的可能性不高），這是如果有另外一個(gè)功能也需要使用這個(gè)模塊的功能，但是對(duì)應(yīng)的是一套完全不同的接口，這時(shí)適配器就可以發(fā)揮作用了。

　　適配器模式分為兩種，一種是對(duì)象適配器，一種是類適配器，對(duì)象適配器的UML圖如下：

　　這里Adaptee1和Adaptee2指兩套不同的子系統(tǒng)，它們作為Adapter的屬性存在，可以使用IoC的方式指定。

　　類適配器的UML圖如下：
　　

　　同樣是兩個(gè)不同的子系統(tǒng)，但是這里我們創(chuàng)建了2個(gè)Adapter類來(lái)分別指向兩個(gè)子系統(tǒng)。在這里我們可以在Client和ITarget之間，設(shè)置一個(gè)Adapter工廠，來(lái)根據(jù)業(yè)務(wù)需求創(chuàng)建不同的Adpater實(shí)例。
　　2）裝飾（Decorator），假如我們已經(jīng)開(kāi)發(fā)了一套功能，然后根據(jù)需求，需要增加一些子功能，而且這些子功能是比較分散比較時(shí)可以增刪的，這時(shí)如果直接修改接口，那么會(huì)造成接口功能復(fù)雜并且不穩(wěn)定，針對(duì)這種情況，我們可以使用裝飾模式。對(duì)應(yīng)的UML圖如下：

　　上圖中，ConcreteComponent已經(jīng)實(shí)現(xiàn)了Component的基本功能，對(duì)于一些附加的功能，如果放在 ConcreteComponent中不合適的話，我們可以像ConcreteDecoratorA一樣，創(chuàng)建一個(gè)基于Decorator的類，通過(guò) SetComponent方法將核心功能和輔助功能串在一起。

　　有時(shí)，為了簡(jiǎn)單，我們也可以把ConcreteDecorator直接掛在Concretecomponent下面。

　　3）橋接器（Bridge）， 面向?qū)ο筇岢膸讉€(gè)最佳實(shí)踐包括：1）封裝變化；2）面向接口編程；3）組合優(yōu)于繼承；4）類的職責(zé)盡量單一。橋接器完美的體現(xiàn)了這些，通過(guò)創(chuàng)建型模式， 我們可以很好地達(dá)到面向接口編程的目標(biāo)，也就是說(shuō)我們?cè)诔绦蛑懈髯兞康穆暶黝愋褪墙涌陬愋突蛘叱橄箢?，而具體的實(shí)現(xiàn)類型則由不同的設(shè)計(jì)模式使用不同方式指 定。這在接口或者抽象類基本穩(wěn)定的情況下，是很好地，但當(dāng)接口需要發(fā)生變化時(shí)，我們?nèi)绾稳ヌ幚?？可以看看橋接器的UML圖：

　　通過(guò)這個(gè)圖，我們可以看出，Implementor接口的變化，對(duì)于Client來(lái)說(shuō)，基本是沒(méi)有影響的。Abstraction會(huì)持有Implementor的一個(gè)實(shí)例。

　　4）享元（FlyWeight）， 當(dāng)我們系統(tǒng)中需要使用大量的小對(duì)象，但我們又不希望將所有的小對(duì)象都創(chuàng)建出來(lái)時(shí)，可以考慮使用享元模式，它會(huì)抽取小對(duì)象中的公共部分，將其封裝為基類，然 后針對(duì)不同條件創(chuàng)建小對(duì)象，同時(shí)在對(duì)象池中維護(hù)這些小對(duì)象，客戶在需要使用小對(duì)象時(shí)，首先在對(duì)象池中查找，如果存在，直接返回。對(duì)于小對(duì)象中“個(gè)性”的部 分，由調(diào)用小對(duì)象的客戶端進(jìn)行維護(hù)。對(duì)應(yīng)的UML圖如下：
　　

　　除了上述的簡(jiǎn)單享元，還存在一種復(fù)合享元，對(duì)應(yīng)的UML圖如下：

　　圖中，CompositeConcreteComponent是不共享的，但是它里面包含很多簡(jiǎn)單的享元，這些享元是共享的，我們可以把它想象成一個(gè)特殊的“享元工廠”。

　　通常提到享元，最常見(jiàn)的例子就是文本編輯器中的26個(gè)字母，在.NET中，字符串常量也使用了享元模式。

　　在享元模式中，我們通常會(huì)將FlyWeightFactory設(shè)計(jì)為單例模式，否則享元就沒(méi)有意義了。

　　5）門(mén)面（Facade），如果我們的程序需要深入調(diào)用某個(gè)模塊的內(nèi)部，但我們又不想和模塊過(guò)緊耦合，這時(shí)可以考慮使用門(mén)面模式，來(lái)對(duì)外部封裝內(nèi)部子系統(tǒng)的實(shí)現(xiàn)。簡(jiǎn)單的門(mén)面可能和代理在某種程度上很相似。

　　門(mén)面模式?jīng)]有固定的UML圖，它是根據(jù)客戶端的實(shí)際需求以及子系統(tǒng)內(nèi)部的接口來(lái)確定的。

　　6）合成（Composite），當(dāng)我們的對(duì)象結(jié)構(gòu)中存在“父子”關(guān)系時(shí)，可以考慮使用合成模式。它分為兩種，一種是安全型的合成模式，UML圖如下：

　　這種類型的合成模式，對(duì)于Component的增、刪、改，都在Composite中維護(hù)，Leaf根本不知道這些操作。另一種是透明型的合成模式，UML圖如下：

　　這種類型的合成模式，自上而下所有的Component都會(huì)有增、刪、改的操作，只不過(guò)對(duì)于Leaf來(lái)說(shuō)，這些操作時(shí)沒(méi)有意義的。

　　7）代理（Proxy），在編寫(xiě)程序時(shí)，有時(shí)我們希望使用某個(gè)對(duì)象或者模塊的功能，但是因?yàn)榉N種原因，我們不能直接訪問(wèn)，這時(shí)就可以考慮使用代理，對(duì)應(yīng)的UML圖如下：

　　需要注意的是，在這里RealSubject只有一個(gè)，如果有多個(gè)，那么就是Adapter了。另外，代理也可以加入自己的一些邏輯處理，例如PreExecute和PostExecute。如果這里有多個(gè)Proxy，那么就是Decorator了。

　　上面就是對(duì)結(jié)構(gòu)型設(shè)計(jì)模式的快速瀏覽，其中有很多UML圖看上去很相似，但深入去思考，每個(gè)模式的出發(fā)點(diǎn)、所要解決的問(wèn)題是不一樣的。

#p#

設(shè)計(jì)模式之行為型模式

在這部分里，我們關(guān)注GoF設(shè)計(jì)模式中的行為型模式，它是用來(lái)在不同對(duì)象之間劃分職責(zé)和算法的抽象，行為模式不僅涉及到類和對(duì)象，還涉及到類與對(duì)象之間如何進(jìn)行關(guān)聯(lián)。

　　行為型模式包括：職責(zé)鏈（Chain of Responsibility）、命令（Command）、解釋器（Interperter）、迭代（Iterator）、中介者（Mediator）、備忘錄（Memento）、觀察者（Observer）、狀態(tài)（State）、策略（Strategy）、模板（Template）和訪問(wèn)者（Visitor）。我們主要討論其中的一部分模式，后續(xù)會(huì)有其他補(bǔ)充。

　　1） 職責(zé)鏈（Chain of Responsibility），如果完成一項(xiàng)業(yè)務(wù)，需要很多步相關(guān)操作，但是如果將這些操作完全封裝到一個(gè)類或者方法里面，又違背了單一職責(zé)的原則。這時(shí)我們可以考慮使用職責(zé)鏈模式，對(duì)應(yīng)的UML圖如下：

　　我們可以創(chuàng)建很多個(gè)Handler的實(shí)現(xiàn)類，并通過(guò)設(shè)置Successor來(lái)將這些Handler“串”在一起。那么如何觸發(fā)所有的Handler呢？這里和Decorator有點(diǎn)兒類似，我們可以通過(guò)調(diào)用 Successor.HandlerRequest來(lái)實(shí)現(xiàn)。這樣用戶只需要關(guān)心最開(kāi)始的Handler，而不必關(guān)心后面都還有哪些其他的Handler。

　　2）命令（Command），命令模式將發(fā)出命令和執(zhí)行命令很好的區(qū)分開(kāi)來(lái)，當(dāng)我們執(zhí)行某項(xiàng)業(yè)務(wù)時(shí)，客戶端只需要構(gòu)造一個(gè)請(qǐng)求，而不必關(guān)心業(yè)務(wù)實(shí)現(xiàn)的具體細(xì)節(jié)，即構(gòu)造請(qǐng)求和業(yè)務(wù)實(shí)現(xiàn)是獨(dú)立的。對(duì)應(yīng)的UML圖如下：

　　從圖中，我們可以看到，當(dāng)Client端需要執(zhí)行某項(xiàng)業(yè)務(wù)時(shí)，它需要構(gòu)造一個(gè)Invoker對(duì)象，它負(fù)責(zé)發(fā)出請(qǐng)求，會(huì)生成一個(gè)Command對(duì)象。同時(shí)我們看到有一個(gè)Receiver對(duì)象，它是用來(lái)實(shí)現(xiàn)具體業(yè)務(wù)的，我們?cè)贑oncreteCommand中，會(huì)引用這個(gè)對(duì)象，來(lái)完成具體業(yè)務(wù)。

　　3）觀察者（Observer），當(dāng)我們的系統(tǒng)中，存在一個(gè)業(yè)務(wù)A，有其他多個(gè)業(yè)務(wù)都需要關(guān)注業(yè)務(wù)A，當(dāng)它的狀態(tài)發(fā)生變化時(shí)，其他業(yè)務(wù)都需要做出相應(yīng)操作，這時(shí)我們可以使用觀察者模式。觀察者模式也稱作訂閱模式，它會(huì)定義一個(gè)“主題”（業(yè)務(wù)A），一個(gè)抽象的“訂閱者”以及很多具體的“訂閱者”（其他業(yè)務(wù)），在“主題”中，會(huì)保留所有“訂閱者”的引用，同時(shí)可以對(duì)“訂閱者”進(jìn)行添加或者刪除，當(dāng)“主題”的狀態(tài)發(fā)生變化時(shí)，它會(huì)主動(dòng)“通知”所有“訂閱者”，從而“訂閱者”可以做出相應(yīng)的操作。對(duì)應(yīng)的UML圖如下：

　　我們可以看到ConcreteSubject中保留了多個(gè)Subscriber的引用（Subscribers），在NotifySubscriber方法中，它會(huì)依次調(diào)用每個(gè)Subscriber的Update方法，從而更新“訂閱者”的狀態(tài)。

　　4）訪問(wèn)者（Visitor），當(dāng)我們有一個(gè)對(duì)象集合，集合中的元素類型是不一樣的，但類型是相對(duì)固定的，例如只有3種不同的類型，但是可能有30個(gè)元素。如果我們希望對(duì)集合中的所有元素進(jìn)行某種操作，從接口的角度來(lái)看，由于類型不一致，我們很難通過(guò)一個(gè)統(tǒng)一的接口來(lái)遍歷集合元素并對(duì)其進(jìn)行操作。這時(shí)我們可以考慮使用訪問(wèn)者模式，它將獲取某個(gè)元素和對(duì)元素進(jìn)行操作進(jìn)行了分離。對(duì)應(yīng)的UML圖如下：

　　這里我們假設(shè)集合中只包括了2中不同的類型，ObjectBuilder就是上面提到的集合，它包含多個(gè)不同的IElement元素，業(yè)務(wù)的核心實(shí)現(xiàn)是在VisitorA和VisitorB中，對(duì)于Element1的Accept 方法來(lái)說(shuō)，它只是調(diào)用visitor.VisitElement1方法。

　　5）模板（Template），繼承是面向?qū)ο蟮囊淮蠛诵?，而模板方法就是?duì)繼承的完美體現(xiàn)。對(duì)于某項(xiàng)業(yè)務(wù)來(lái)說(shuō)，我們可以根據(jù)通用的流程，設(shè)計(jì)其方法骨架，針對(duì)不清晰或者不明確的地方，以抽象方法的方式來(lái)處理，然后根據(jù)不同的子業(yè)務(wù)，創(chuàng)建不同的子類，在子類中，實(shí)現(xiàn)那些抽象方法。對(duì)應(yīng)的UML圖如下：

　　可以看出，對(duì)于子類來(lái)說(shuō)，它是不需要重寫(xiě)Operate方法的，而只需要實(shí)現(xiàn)父類的抽象方法。對(duì)于客戶端來(lái)說(shuō)，當(dāng)它實(shí)例化某個(gè)子類后，可以直接調(diào)用Operate方法來(lái)完成某項(xiàng)業(yè)務(wù)。

　　6）策略（Strategy），當(dāng)我們的系統(tǒng)中，針對(duì)某項(xiàng)業(yè)務(wù)有多個(gè)算法時(shí)，如何對(duì)這些算法進(jìn)行管理，我們可以考慮使用策略模式，它主要是針對(duì)一組可以提取相同接口的算法進(jìn)行管理。對(duì)應(yīng)的UML圖如下：

　　這里需要注意的是，Strategy類并不知道應(yīng)該使用哪個(gè)具體的子類，這應(yīng)該由Client指定。

　　7）解釋器（Interperter），如果我們的系統(tǒng)中有些特定的問(wèn)題反復(fù)出現(xiàn)，我們想要對(duì)這些問(wèn)題進(jìn)行抽象，那應(yīng)該如何做？試想一下，當(dāng)我們寫(xiě)完代碼后，是如何進(jìn)行編譯的？無(wú)論對(duì)C#還是 Java，它們的編譯器都會(huì)讀取我們所寫(xiě)的每一行代碼，并作出相應(yīng)的解釋。我們可以部分認(rèn)為，編譯器中存儲(chǔ)了任何組合的語(yǔ)句，類似于C中的 typedef。解釋器做的就是類似的事情，它將具有通用性的問(wèn)題進(jìn)行抽取，對(duì)其解決方案進(jìn)行綜合處理。對(duì)應(yīng)的UML圖如下：

　　一般的執(zhí)行過(guò)程是這樣的，Client讀取Context中的信息，根據(jù)某種原則將其劃分成多個(gè)部分，針對(duì)每一部分，構(gòu)造相應(yīng)的解釋器，并將Context信息傳入解釋器中進(jìn)行處理。這里的問(wèn)題是Client必須要清楚 Context細(xì)節(jié)和具體解釋器中間的關(guān)聯(lián)。我們可以在Client和Interpreter之間構(gòu)造一個(gè)“解釋器工廠”，用來(lái)根據(jù)Context生成相應(yīng)的解釋器實(shí)例，同樣，如果解釋器的執(zhí)行過(guò)程和數(shù)據(jù)無(wú)關(guān)，我們可以為“解釋器工廠”上追加“單例”模式，構(gòu)造一個(gè)解釋器池。這些都是可以根據(jù)需求做的進(jìn)一步的優(yōu)化。

　　8）迭代（Iterator），前文提到的訪問(wèn)者（Visitor）模式，針對(duì)的是存儲(chǔ)在一起的不同類型的對(duì)象集合，如何進(jìn)行遍歷處理，那么針對(duì)存儲(chǔ)在一起的相同類型的對(duì)象集合，我們應(yīng)該如何進(jìn)行遍歷呢？迭代模式可以幫我們做到，對(duì)應(yīng)的UML圖如下：

　　在C#和Java中，我們都已經(jīng)在語(yǔ)言層級(jí)上實(shí)現(xiàn)了迭代，例如C#中的foreach，同時(shí).NET來(lái)設(shè)計(jì)了兩個(gè)接口來(lái)實(shí)現(xiàn)迭代：IEnumerator和IEnumerable。

　　9）中介者（Mediator），如果我們的系統(tǒng)中有多個(gè)對(duì)象，彼此之間都有聯(lián)系，那這是一個(gè)對(duì)象之間耦合很高的系統(tǒng)，我們應(yīng)該如何優(yōu)化呢？我們可以建立一個(gè)知道所有對(duì)象的“對(duì)象”，在它內(nèi)部維護(hù)其他對(duì)象之間的關(guān)聯(lián)，這就是中介者模式，對(duì)應(yīng)的UML圖如下：

　　這里，Mediator是知道所有IPerson的“底細(xì)”的，Client 可以直接與Mediator聯(lián)系，而不必關(guān)心具體的是PersonA還是PersonB，同樣，對(duì)于PersonA和PersonB來(lái)說(shuō)，它們之間也沒(méi)有直接聯(lián)系，當(dāng)兩者需要通信時(shí)，之金額使用Mediator的Send方法。

　　這個(gè)模式不好的地方在于：1）所有的IPerson類型都要有 Mediator引用，這樣才能和其他的Person通信；2）Mediator需要維護(hù)所有Person的實(shí)例，這樣它才能做出正確的判斷，將消息發(fā)給對(duì)應(yīng)的Person，但當(dāng)Person子類過(guò)多時(shí)，Mediator就變的較難維護(hù)，這時(shí)，我們可以創(chuàng)建一套關(guān)于產(chǎn)生Person實(shí)例的“工廠”，會(huì)減輕 Mediator的負(fù)擔(dān)。

　　10）備忘錄（Memento），當(dāng)我們的系統(tǒng)中存在這樣一種對(duì)象，它的屬性很多，在某些情況下，它的一部分屬性是需要進(jìn)行備份和恢復(fù)的，那應(yīng)該如何做？談到備份和恢復(fù)，我們立刻想到可以使用原型模式，但那是針對(duì)所有屬性的，備忘錄模式可以很好地解決這里的問(wèn)題，對(duì)應(yīng)的UML圖如下：

　　在這里，我們希望Originator的State2、State3是可以備份和恢復(fù)的，其他屬性是無(wú)關(guān)的。我們可以在希望備份Originator的地方，調(diào)用Creatememento方法，在希望恢復(fù)Originator部分屬性的地方，調(diào)用RestoreMemento方法，同時(shí)MementoManager對(duì)Memento進(jìn)行管理。

　　11）狀態(tài)（State），當(dāng)我們的系統(tǒng)中的對(duì)象，需要根據(jù)傳入的不同參數(shù)，進(jìn)行不同的處理，而且傳入?yún)?shù)的種類特別多，這時(shí)在方法內(nèi)部會(huì)產(chǎn)生大量的if語(yǔ)句，來(lái)確定方法的執(zhí)行分支。那么如何消除這些if語(yǔ)句呢？狀態(tài)模式可以幫我們做到，對(duì)應(yīng)的UML圖如下：

　　這里，Client只與Context關(guān)聯(lián)，在Context內(nèi)部，會(huì)維護(hù)不同狀態(tài)之間的跳轉(zhuǎn)，簡(jiǎn)單來(lái)說(shuō)，就是在HandleRequest內(nèi)部判斷傳入的state值，如果符合業(yè)務(wù)邏輯，那么直接調(diào)用state的 HandleRequest方法；如果不符合，那么修改state值，然后調(diào)用相應(yīng)state的HandleRequest方法。

原文鏈接：http://www.cnblogs.com/wing011203/archive/2013/05/02/3055299.html