從2005年初聽說設計模式，到現在雖然已經8年多了，但GoF的23種模式依然盛行，當然GoF提出這些模式的年代更加久遠（1995年）。

　　在工作的過程中，陸陸續續接觸了GoF的大部分模式，我記得在2008年的時候就想總結一 下設計模式（最近想做的兩件事情），最后因為各種原因也沒有完成。最近這段時間正好是職業空檔期，沒什么事兒做，就把之前看過的設計模式翻出來整理了一 下，于是就有了上面幾篇文章。

　　整理設計模式的過程，也是一個深刻理解面向對象設計的過程。通過對各個模式的回顧，讓我更能夠明白前輩們關于面向對象設計提出的各種“最佳實踐”，特別是S.O.L.I.D，我覺得在這里再說一次，也不算矯情。

　　S：單一職責原則（Single Responsibility Principle, SRP），一個類只能有一個原因使其發生改變，即一個類只承擔一個職責。

　　O：開放-封閉原則（Open-Close Principle, OCP），這里指我們的設計應該針對擴展開放，針對修改關閉，即盡量以擴展的方式來維護系統。

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

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

　　D：依賴倒置原則（Dependence Inversion Principle, DIP），高層模塊不應該依賴于低層模塊，兩者應該都依賴于抽象；抽象不依賴于細節，而細節應該依賴于抽象。這里主要是提倡“面向接口”編程，而非“面向實現”編程。

　　設計模式，從本質上講，是針對過去某種經驗的總結。每種設計模式，都是為了在特定條件下去解決特定問題，離開這些前提去討論設計模式，是沒有意義的。

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

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

　　上面是對GoF23中模式的快速回顧，其中的理解未必很深刻很到位。對設計模式的學習是沒有止境的，而且它也只是面向對象分析與設計的冰山一偶

#p#

設計模式之創建型模式

　　GoF的設計模式一共23個，可以分為3大類：創建型、結構型和行為型，這篇文章主要討論創建型。

　　創建型的設計模式包括：簡單工廠（Simple Factory）、工廠方法（Factory Method）、抽象工廠（Abstract Factory）、單例（Singleton）、構造者（Builder）和原型（Prototype），我們分別來討論。

　　我們首先來看工廠系列的3個設計模式，它們都主要是針對軟件設計中的“開放-封閉”原則， 即程序應該對擴展開放，對修改封閉。特別是當我們的程序采用XML+反射的方式來創建對象時，工廠模式的威力就完全展現出來了，這時我們可以通過維護配置 文件的方式，來控制程序的邏輯。

　　1）簡單工廠，當我們的程序在實例化對象時，如果輸入條件不一樣，產生的對象也不一樣，那么我們可以考慮使用簡單工廠對不同的實例進行統一封裝， UML結構如下：

　　　　

　　優點：封裝了具體對象的實例化過程，Client端和具體對象解耦，同時ProductManager可以作成靜態類或者Singleton對象，然后可以使用HashMap緩存具體對象（前提是對象沒有時間依賴性），降低創建對象的次數。

　　缺點：當增添一種新類型的對象時，需要修改Productmanager的代碼（如果不采用XML）

　　2）工廠方法，它是針對簡單工廠的改進版，添加了對ProductManager的抽象，UML結構如下：

　　　　

　　優點：結構更加靈活，對于某種類型的對象來說，會有一個特定的對象工廠指向它，這樣當我們需要添加一種新類型的產品時，只需要添加兩個類，一個是具體產品類，一個是新產品的工廠類。這樣更加靈活。

　　缺點：結構開始變得復雜，而且最終還是需要Client端來確定究竟使用哪一個Factory（當然這個信息可以保存在上下文或者配置文件中）。

　　3）抽象工廠，這個是最復雜的工廠模式，它用來生成一個產品線上的所有產品，我們假設一個產品線上包括多個產品，不同的產品線上的產品個數是一樣的，這樣我們需要一個針對產品線的抽象，并且很顯然不同產品線上的產品是不可能混到一起的。對應的UML結構圖如下：

　　

　　上圖表明，一個產品線上的產品由IProduct1和IProduct2組成，客戶端在獲取產品時，這兩個產品應該是同時返回的，因此對于IProductManager來說，它需要同時生成這兩個對象。

　　優點：對創建產品家族的行為高度抽象，添加一個產品線的邏輯比較清晰。

　　缺點：當我們對產品線上的產品進行增加和刪除時，對應的操作比較麻煩，所有的產品工廠都需要進行修改。

　　4）單例，這是比較好理解的一個模式，從字面上說，就是程序在運行的過程中，希望在任意時刻，都只保留某個對象的唯一實例。對應的UML結構圖如下：

　　

　　單例的實現方式一般包括幾步：1）私有的指向自身的字段；2）私有構造函數；3）公開對私有字段進行實例化的方法。也有幾種針對具體語言進行的改善，例如針對多線程采用double lock機制，采用常量方式定義私有字段、使用內嵌類來實例化字段等。

　　我們也可以對單例進行一些適當的擴展，例如我們將對象的個數由1個變為N個，這就成了對象池。

　　通常工廠模式中會使用到單例模式，特別是對于簡單工廠來說。

　　5）構造者，對于一些復雜對象來說，它可以分成多個不同的部分，在實例化時，不同部分之間實例化的順序，有時會有嚴格的限制，這時我們就可以使用構造者模式了。對應的UML結構圖如下：

　　

　　我們定義了IBuilder接口來實例化對應的不同部分，同時有一個方法來返回對象的實例。而Constructor類的Construct方 法會按照業務邏輯依次調用實例化部分對象的方法，即BuildPartA、BuildPartB，這里的調用順序，完全由業務邏輯來控制，最后可以調用 GetProduct方法取得完整的對象實例。

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

　　6）原型，我們在程序運行過程中，當需要有新的實例對象時，有時并不希望是從頭創建一個對象，而是希望新的實例的狀態和某個已存在的實例保持一致，這就是原型模式發揮作用的地方。對應的UML結構圖如下：

　　

　　在.NET中，已經定義了IClonable接口來實現原型模式。需要注意在實現時，會有深拷貝和淺拷貝的區別，深拷貝會同時拷貝堆棧和堆上的內容，而淺拷貝只會拷貝堆棧上的內容。

#p#

設計模式之結構型模式

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

　　下面我們對上面提到的模式分別進行描述。

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

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

 

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

　　類適配器的UML圖如下：
　　

　　同樣是兩個不同的子系統，但是這里我們創建了2個Adapter類來分別指向兩個子系統。在這里我們可以在Client和ITarget之間，設置一個Adapter工廠，來根據業務需求創建不同的Adpater實例。
　　2）裝飾（Decorator），假如我們已經開發了一套功能，然后根據需求，需要增加一些子功能，而且這些子功能是比較分散比較時可以增刪的，這時如果直接修改接口，那么會造成接口功能復雜并且不穩定，針對這種情況，我們可以使用裝飾模式。對應的UML圖如下：

　　

　　上圖中，ConcreteComponent已經實現了Component的基本功能，對于一些附加的功能，如果放在 ConcreteComponent中不合適的話，我們可以像ConcreteDecoratorA一樣，創建一個基于Decorator的類，通過 SetComponent方法將核心功能和輔助功能串在一起。

　　有時，為了簡單，我們也可以把ConcreteDecorator直接掛在Concretecomponent下面。

　　3）橋接器（Bridge）， 面向對象提倡的幾個最佳實踐包括：1）封裝變化；2）面向接口編程；3）組合優于繼承；4）類的職責盡量單一。橋接器完美的體現了這些，通過創建型模式， 我們可以很好地達到面向接口編程的目標，也就是說我們在程序中各變量的聲明類型是接口類型或者抽象類，而具體的實現類型則由不同的設計模式使用不同方式指 定。這在接口或者抽象類基本穩定的情況下，是很好地，但當接口需要發生變化時，我們如何去處理？可以看看橋接器的UML圖：

　　

　　通過這個圖，我們可以看出，Implementor接口的變化，對于Client來說，基本是沒有影響的。Abstraction會持有Implementor的一個實例。

　　4）享元（FlyWeight）， 當我們系統中需要使用大量的小對象，但我們又不希望將所有的小對象都創建出來時，可以考慮使用享元模式，它會抽取小對象中的公共部分，將其封裝為基類，然 后針對不同條件創建小對象，同時在對象池中維護這些小對象，客戶在需要使用小對象時，首先在對象池中查找，如果存在，直接返回。對于小對象中“個性”的部 分，由調用小對象的客戶端進行維護。對應的UML圖如下：
　　

　　除了上述的簡單享元，還存在一種復合享元，對應的UML圖如下：

　　

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

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

　　在享元模式中，我們通常會將FlyWeightFactory設計為單例模式，否則享元就沒有意義了。

　　5）門面（Facade），如果我們的程序需要深入調用某個模塊的內部，但我們又不想和模塊過緊耦合，這時可以考慮使用門面模式，來對外部封裝內部子系統的實現。簡單的門面可能和代理在某種程度上很相似。

　　門面模式沒有固定的UML圖，它是根據客戶端的實際需求以及子系統內部的接口來確定的。

　　6）合成（Composite），當我們的對象結構中存在“父子”關系時，可以考慮使用合成模式。它分為兩種，一種是安全型的合成模式，UML圖如下：

　　

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

　　

　　這種類型的合成模式，自上而下所有的Component都會有增、刪、改的操作，只不過對于Leaf來說，這些操作時沒有意義的。

　　7）代理（Proxy），在編寫程序時，有時我們希望使用某個對象或者模塊的功能，但是因為種種原因，我們不能直接訪問，這時就可以考慮使用代理，對應的UML圖如下：

　　

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

　　上面就是對結構型設計模式的快速瀏覽，其中有很多UML圖看上去很相似，但深入去思考，每個模式的出發點、所要解決的問題是不一樣的。

#p#

設計模式之行為型模式

在這部分里，我們關注GoF設計模式中的行為型模式，它是用來在不同對象之間劃分職責和算法的抽象，行為模式不僅涉及到類和對象，還涉及到類與對象之間如何進行關聯。

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

　　1） 職責鏈（Chain of Responsibility），如果完成一項業務，需要很多步相關操作，但是如果將這些操作完全封裝到一個類或者方法里面，又違背了單一職責的原則。這時我們可以考慮使用職責鏈模式，對應的UML圖如下：

　　我們可以創建很多個Handler的實現類，并通過設置Successor來將這些Handler“串”在一起。那么如何觸發所有的Handler呢？這里和Decorator有點兒類似，我們可以通過調用 Successor.HandlerRequest來實現。這樣用戶只需要關心最開始的Handler，而不必關心后面都還有哪些其他的Handler。

　　2）命令（Command），命令模式將發出命令和執行命令很好的區分開來，當我們執行某項業務時，客戶端只需要構造一個請求，而不必關心業務實現的具體細節，即構造請求和業務實現是獨立的。對應的UML圖如下：

　　

　　從圖中，我們可以看到，當Client端需要執行某項業務時，它需要構造一個Invoker對象，它負責發出請求，會生成一個Command對象。同時我們看到有一個Receiver對象，它是用來實現具體業務的，我們在ConcreteCommand中，會引用這個對象，來完成具體業務。

　　3）觀察者（Observer），當我們的系統中，存在一個業務A，有其他多個業務都需要關注業務A，當它的狀態發生變化時，其他業務都需要做出相應操作，這時我們可以使用觀察者模式。觀察者模式也稱作訂閱模式，它會定義一個“主題”（業務A），一個抽象的“訂閱者”以及很多具體的“訂閱者”（其他業務），在“主題”中，會保留所有“訂閱者”的引用，同時可以對“訂閱者”進行添加或者刪除，當“主題”的狀態發生變化時，它會主動“通知”所有“訂閱者”，從而“訂閱者”可以做出相應的操作。對應的UML圖如下：

　　

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

　　4）訪問者（Visitor），當我們有一個對象集合，集合中的元素類型是不一樣的，但類型是相對固定的，例如只有3種不同的類型，但是可能有30個元素。如果我們希望對集合中的所有元素進行某種操作，從接口的角度來看，由于類型不一致，我們很難通過一個統一的接口來遍歷集合元素并對其進行操作。這時我們可以考慮使用訪問者模式，它將獲取某個元素和對元素進行操作進行了分離。對應的UML圖如下：

　　

　　這里我們假設集合中只包括了2中不同的類型，ObjectBuilder就是上面提到的集合，它包含多個不同的IElement元素，業務的核心實現是在VisitorA和VisitorB中，對于Element1的Accept 方法來說，它只是調用visitor.VisitElement1方法。

　　5）模板（Template），繼承是面向對象的一大核心，而模板方法就是對繼承的完美體現。對于某項業務來說，我們可以根據通用的流程，設計其方法骨架，針對不清晰或者不明確的地方，以抽象方法的方式來處理，然后根據不同的子業務，創建不同的子類，在子類中，實現那些抽象方法。對應的UML圖如下：

　　

　　可以看出，對于子類來說，它是不需要重寫Operate方法的，而只需要實現父類的抽象方法。對于客戶端來說，當它實例化某個子類后，可以直接調用Operate方法來完成某項業務。

　　6）策略（Strategy），當我們的系統中，針對某項業務有多個算法時，如何對這些算法進行管理，我們可以考慮使用策略模式，它主要是針對一組可以提取相同接口的算法進行管理。對應的UML圖如下：

　　

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

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

　　

　　一般的執行過程是這樣的，Client讀取Context中的信息，根據某種原則將其劃分成多個部分，針對每一部分，構造相應的解釋器，并將Context信息傳入解釋器中進行處理。這里的問題是Client必須要清楚 Context細節和具體解釋器中間的關聯。我們可以在Client和Interpreter之間構造一個“解釋器工廠”，用來根據Context生成相應的解釋器實例，同樣，如果解釋器的執行過程和數據無關，我們可以為“解釋器工廠”上追加“單例”模式，構造一個解釋器池。這些都是可以根據需求做的進一步的優化。

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

　　

　　在C#和Java中，我們都已經在語言層級上實現了迭代，例如C#中的foreach，同時.NET來設計了兩個接口來實現迭代：IEnumerator和IEnumerable。

　　9）中介者（Mediator），如果我們的系統中有多個對象，彼此之間都有聯系，那這是一個對象之間耦合很高的系統，我們應該如何優化呢？我們可以建立一個知道所有對象的“對象”，在它內部維護其他對象之間的關聯，這就是中介者模式，對應的UML圖如下：

　　

　　這里，Mediator是知道所有IPerson的“底細”的，Client 可以直接與Mediator聯系，而不必關心具體的是PersonA還是PersonB，同樣，對于PersonA和PersonB來說，它們之間也沒有直接聯系，當兩者需要通信時，之金額使用Mediator的Send方法。

　　這個模式不好的地方在于：1）所有的IPerson類型都要有 Mediator引用，這樣才能和其他的Person通信；2）Mediator需要維護所有Person的實例，這樣它才能做出正確的判斷，將消息發給對應的Person，但當Person子類過多時，Mediator就變的較難維護，這時，我們可以創建一套關于產生Person實例的“工廠”，會減輕 Mediator的負擔。

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

　　

　　在這里，我們希望Originator的State2、State3是可以備份和恢復的，其他屬性是無關的。我們可以在希望備份Originator的地方，調用Creatememento方法，在希望恢復Originator部分屬性的地方，調用RestoreMemento方法，同時MementoManager對Memento進行管理。

　　11）狀態（State），當我們的系統中的對象，需要根據傳入的不同參數，進行不同的處理，而且傳入參數的種類特別多，這時在方法內部會產生大量的if語句，來確定方法的執行分支。那么如何消除這些if語句呢？狀態模式可以幫我們做到，對應的UML圖如下：

　　

　　這里，Client只與Context關聯，在Context內部，會維護不同狀態之間的跳轉，簡單來說，就是在HandleRequest內部判斷傳入的state值，如果符合業務邏輯，那么直接調用state的 HandleRequest方法；如果不符合，那么修改state值，然后調用相應state的HandleRequest方法。

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