前言
在實際開發中,我們經常會遇到這種情況;一個對象有多種狀態,在每一個狀態下,都會有不同的行為。那么在代碼中我們經常是這樣實現的。
而這種就好比簡單工廠模式,當我們增加新的狀態類型時,我們又需要修改原來的代碼,這種對于測試是很不利的;由于簡單工廠的缺點那么的明顯,后來的工廠模式就克服了這個缺點,我們就可以借鑒工程模式,來解決這種隨著狀態增加而出現的多分支結構,而這就是我今天要總結的狀態模式。
狀態模式
在GOF的《設計模式:可復用面向對象軟件的基礎》一書中對狀態模式是這樣說的:允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它的類。狀態模式的重點在于狀態轉換,很多時候,對于一個對象的狀態,我們都是讓這個對象包含一個狀態的屬性,這個狀態屬性記錄著對象的具體狀態,根據狀態的不同使用分支結構來執行不同的功能,就像上面的代碼那樣處理;就像上面說的,類中存在大量的結構類似的分支語句,變得難以維護和理解。狀態模式消除了分支語句,就像工廠模式消除了簡單工廠模式的分支語句一樣,將狀態處理分散到各個狀態子類中去,每個子類集中處理一種狀態,這樣就使得狀態的處理和轉換清晰明確。
UML類圖
Context:定義客戶端感興趣的接口,并且維護一個ConcreteState子類的實例,這個實例定義當前狀態;
State:定義一個接口以封裝與Context的一個特定狀態相關的行為;
ConcreteState subclasses:每一個子類實現一個與Context的一個狀態相關的行為。
它們之間的協作步驟如下:
1.Context將與狀態相關的請求委托給當前的ConcreteState對象處理;
2.Context可以將自身作為一個參數傳遞給處理該請求的狀態對象。這使得狀態對象在必要時可以訪問Context;
3.Context是客戶使用的主要接口。客戶可用狀態對象來配置一個Context,一旦一個Context配置完畢,它的客戶不再需要直接與狀態對象打交道;
使用場合
在以下兩種情況下均可使用State模式:
1.一個對象的行為取決于它的狀態,并且它必須在運行時刻根據狀態改變它的行為;
2.一個操作中含有龐大的多分支的條件語句,且這些分支依賴于該對象的狀態。這個狀態通常用一個或多個枚舉常量表示。通常有多個操作包含這一相同的條件結構。State模式將每一個條件分支放入一個獨立的類中。這使得你可以根據對象自身的情況將對象的狀態作為一個對象,這一對象可以不依賴于其它對象而獨立變化。
代碼實現:
總結
狀態模式總的來說是非常好理解的;沒有多么深奧的時序關系,就是簡單的將對象的狀態和對應狀態下的行為分離開來,不再是簡單的if…else或switch…case分支結構了,而是每一個狀態都對應一個類,一個類集中管理一個狀態;在多狀態的情況下,簡化了程序的維護和管理,讓程序結構簡明化,同時也易于擴展。
新聞熱點
疑難解答
圖片精選