前言

在實際開發(fā)中，我們經(jīng)常會遇到這種情況；一個對象有多種狀態(tài)，在每一個狀態(tài)下，都會有不同的行為。那么在代碼中我們經(jīng)常是這樣實現(xiàn)的。

而這種就好比簡單工廠模式，當(dāng)我們增加新的狀態(tài)類型時，我們又需要修改原來的代碼，這種對于測試是很不利的；由于簡單工廠的缺點那么的明顯，后來的工廠模式就克服了這個缺點，我們就可以借鑒工程模式，來解決這種隨著狀態(tài)增加而出現(xiàn)的多分支結(jié)構(gòu)，而這就是我今天要總結(jié)的狀態(tài)模式。

狀態(tài)模式

在GOF的《設(shè)計模式:可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中對狀態(tài)模式是這樣說的：允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它的類。狀態(tài)模式的重點在于狀態(tài)轉(zhuǎn)換，很多時候，對于一個對象的狀態(tài)，我們都是讓這個對象包含一個狀態(tài)的屬性，這個狀態(tài)屬性記錄著對象的具體狀態(tài)，根據(jù)狀態(tài)的不同使用分支結(jié)構(gòu)來執(zhí)行不同的功能，就像上面的代碼那樣處理；就像上面說的，類中存在大量的結(jié)構(gòu)類似的分支語句，變得難以維護(hù)和理解。狀態(tài)模式消除了分支語句，就像工廠模式消除了簡單工廠模式的分支語句一樣，將狀態(tài)處理分散到各個狀態(tài)子類中去，每個子類集中處理一種狀態(tài)，這樣就使得狀態(tài)的處理和轉(zhuǎn)換清晰明確。

UML類圖

Context：定義客戶端感興趣的接口，并且維護(hù)一個ConcreteState子類的實例，這個實例定義當(dāng)前狀態(tài)；
State：定義一個接口以封裝與Context的一個特定狀態(tài)相關(guān)的行為；
ConcreteState subclasses：每一個子類實現(xiàn)一個與Context的一個狀態(tài)相關(guān)的行為。

它們之間的協(xié)作步驟如下：

1.Context將與狀態(tài)相關(guān)的請求委托給當(dāng)前的ConcreteState對象處理；
2.Context可以將自身作為一個參數(shù)傳遞給處理該請求的狀態(tài)對象。這使得狀態(tài)對象在必要時可以訪問Context；
3.Context是客戶使用的主要接口。客戶可用狀態(tài)對象來配置一個Context，一旦一個Context配置完畢，它的客戶不再需要直接與狀態(tài)對象打交道；

使用場合

在以下兩種情況下均可使用State模式：

1.一個對象的行為取決于它的狀態(tài)，并且它必須在運行時刻根據(jù)狀態(tài)改變它的行為；
2.一個操作中含有龐大的多分支的條件語句，且這些分支依賴于該對象的狀態(tài)。這個狀態(tài)通常用一個或多個枚舉常量表示。通常有多個操作包含這一相同的條件結(jié)構(gòu)。State模式將每一個條件分支放入一個獨立的類中。這使得你可以根據(jù)對象自身的情況將對象的狀態(tài)作為一個對象，這一對象可以不依賴于其它對象而獨立變化。

代碼實現(xiàn)：

總結(jié)

狀態(tài)模式總的來說是非常好理解的；沒有多么深奧的時序關(guān)系，就是簡單的將對象的狀態(tài)和對應(yīng)狀態(tài)下的行為分離開來，不再是簡單的if…else或switch…case分支結(jié)構(gòu)了，而是每一個狀態(tài)都對應(yīng)一個類，一個類集中管理一個狀態(tài)；在多狀態(tài)的情況下，簡化了程序的維護(hù)和管理，讓程序結(jié)構(gòu)簡明化，同時也易于擴(kuò)展。