GoF Behavioral - State Pattern

• Intent

在講述這個potic之前，讓我先回想一下我曾經接觸的案子，有個關於公文文件狀態的，公文本身大概有數個到10幾個狀態，對於每一個狀態他有其特定的可使用功能以及樣態表述，傳統的處理作法就是....恩 好吧 我得寫個10 幾個if else....這真是噩夢-.-

這個pattern我一直很感興趣，對於有關乎於 流程以及狀態的設計模式我一直沒有自己做過，而在Head First Design pattern一書當中描述到，若要避免上述的設計方式，大概要這麼做：

1. 定義一個狀態介面，在這介面內的每一個動作都有一個對應方法


2. 為每一個狀態介面實作狀態類別，這些類別將負責在對應的狀態下進行相應的行為


3. 最後，擺脫老舊的條件判斷碼，取而代之的是將動作轉介到狀態類別

這整個模式允許物件隨著內在的狀態改變而改變其行為，好像物件的類別改變了一樣。

有人說策略模式跟這個狀態模式似乎長得一模一樣? yes, you are right ....

圖形是一樣的，但意圖不同!!

• State pattern，將一群行為封裝在狀態物件中，context的行為隨時可以委派到那些狀態物件的其中之一。隨著時間改變，目前狀態將持續改變所有狀態物件的行為，反映出context內部的狀態，因此context的行為也跟著持續改變，但是context的client端對於狀態物件所知不多，甚至完全不會有感覺。


• Strategy pattern，client端通常主動指定context所要合成的策略物件為何者，雖然策略模式較有彈性能在run-time改變策略物件，但對於某個context物件來說，經常只有一個最適當的策略物件

一般來講，要把策略模式想像成除了繼承以外，更有彈性的替代方案，如果要使用繼承定義一個類別的行為，將被這個行為給綁住，甚至要改都很難，而使用策略模式則可藉由組合不同物件改變行為。

而把狀態模式想像成是 不用在 context中放置許多判斷條件的替代方案，藉由將行為包裝進狀態物件中，就可以在context內簡單的改變狀態物件，來改變context的行為。

• Class Diagram

[caption id="attachment_270" align="alignnone" width="630" caption="State Pattern"][/caption]

• Sample Code -(直接看head first dp sample)