State模式的定義 : 不同的狀態,不同的行爲;或者說,每個狀態有着相應的行爲.
何時使用
?
State模式在實際使用中比較多,適合"狀態的切換".因爲我們經常會使用If
elseif else 進行狀態切換,
如果針對狀態的這樣判斷切換反覆出現,我們就要聯想到是否可以採取State模式了.
不只是根據狀態,也有根據屬性.如果某個對象的屬性不同,對象的行爲就不一樣,這點在數據庫系統中出現頻率比較高,我們經常會在一個數據表的尾部,加上 property屬性含義的字段,用以標識記錄中一些特殊性質的記錄,這種屬性的改變(切換)又是隨時可能發生的,就有可能要使用State.
是否使用?
在實際使用,類似開關一樣的狀態切換是很多的,但有時並不是那麼明顯,取決於你的經驗和對系統的理解深度.
這裏要闡述的是"開關切換狀態" 和" 一般的狀態判斷"是有一些區別的, " 一般的狀態判斷"也是有 if..elseif結構,例如:
if (which==1) state="hello";
else if (which==2) state="hi";
else if (which==3) state="bye";
這是一個 " 一般的狀態判斷",state值的不同是根據which變量來決定的,which和state沒有關係.如果改成:
if (state.euqals("bye")) state="hello";
else if (state.euqals("hello")) state="hi";
else if (state.euqals("hi")) state="bye";
這就是 "開關切換狀態",是將state的狀態從"hello"切換到"hi",再切換到""bye";在切換到"hello",好象一個旋轉開關,這種狀態改變就可以使用State模式了.
如果單純有上面一種將"hello"-->"hi"-->"bye"-->"hello"這一個方向切換,也不一定需要使用State模式,因爲State模式會建立很多子類,複雜化,但是如果又發生另外一個行爲:將上面的切換方向反過來切換,或者需要任意切換,就需要State了.
請看下例:
public class Context{ private Color state=null; public void push(){ //如果當前red狀態 就切換到blue public void pull(){ if (state==Color.green) state=Color.blue; } |
在上例中,我們有兩個動作push推和pull拉,這兩個開關動作,改變了Context顏色,至此,我們就需要使用State模式優化它.
另外注意:但就上例,state的變化,只是簡單的顏色賦值,這個具體行爲是很簡單的,State適合巨大的具體行爲,因此在,就本例,實際使用中也不一定非要使用State模式,這會增加子類的數目,簡單的變複雜.
例如: 銀行帳戶, 經常會在Open 狀態和Close狀態間轉換.
例如: 經典的TcpConnection, Tcp的狀態有創建 偵聽 關閉三個,並且反覆轉換,其創建 偵聽 關閉的具體行爲不是簡單一兩句就能完成的,適合使用State
例如:信箱POP帳號, 會有四種狀態, start HaveUsername Authorized quit,每個狀態對應的行爲應該是比較大的.適合使用State
例如:在工具箱挑選不同工具,可以看成在不同工具中切換,適合使用State.如 具體繪圖程序,用戶可以選擇不同工具繪製方框 直線 曲線,這種狀態切換可以使用State.
如何使用
State需要兩種類型實體參與:
1.state manager 狀態管理器 ,就是開關
,如上面例子的Context實際就是一個state manager, 在state
manager中有對狀態的切換動作.
2.用抽象類或接口實現的父類,,不同狀態就是繼承這個父類的不同子類.
以上面的Context爲例.我們要修改它,建立兩個類型的實體.
第一步: 首先建立一個父類:
public abstract class State{ public abstract void handlepush(Context c); } |
父類中的方法要對應state manager中的開關行爲,在state manager中 本例就是Context中,有兩個開關動作push推和pull拉.那麼在狀態父類中就要有具體處理這兩個動作:handlepush() handlepull(); 同時還需要一個獲取push或pull結果的方法getcolor()
下面是具體子類的實現:
public class BlueState extends State{ public void handlepush(Context c){ } //根據pull方法"如果是blue狀態的切換到red" ; } public abstract void getcolor(){ return (Color.blue)} } ? |
同樣 其他狀態的子類實現如blue一樣.
第二步: 要重新改寫State manager 也就是本例的Context:
public class Context{ private Sate state=null; //我們將原來的 Color state 改成了新建的State state; //setState是用來改變state的狀態
使用setState實現狀態的切換 } public void push(){
//狀態的切換的細節部分,在本例中是顏色的變化,已經封裝在子類的handlepush中實現,這裏無需關心 } ? public void pull(){ state.handlepull(this); } } ? |
至此,我們也就實現了State的refactorying過程.
以上只是相當簡單的一個實例,在實際應用中,handlepush或handelpull的處理是複雜的.
狀態模式優點:
(1) 封裝轉換過程,也就是轉換規則
(2) 枚舉可能的狀態,因此,需要事先確定狀態種類。
狀態模式可以允許客戶端改變狀態的轉換行爲,而狀態機則是能夠自動改變狀態,狀態機是一個比較獨立的而且複雜的機制,具體可參考一個狀態機開源項目:http://sourceforge.net/projects/smframework/
狀態模式在工作流或遊戲等各種系統中有大量使用,甚至是這些系統的核心功能設計,例如政府OA中,一個批文的狀態有多種:未辦;正在辦理;正在批示;正在審覈;已經完成等各種狀態,使用狀態機可以封裝這個狀態的變化規則,從而達到擴充狀態時,不必涉及到狀態的使用者。
在網絡遊戲中,一個遊戲活動存在開始;開玩;正在玩;輸贏等各種狀態,使用狀態模式就可以實現遊戲狀態的總控,而遊戲狀態決定了遊戲的各個方面,使用狀態模式可以對整個遊戲架構功能實現起到決定的主導作用。
狀態模式實質
:
使用狀態模式前,客戶端外界需要介入改變狀態,而狀態改變的實現是瑣碎或複雜的。
使用狀態模式後,客戶端外界可以直接使用事件Event實現,根本不必關心該事件導致如何狀態變化,這些是由狀態機等內部實現。
這是一種Event-condition-State,狀態模式封裝了condition-State部分。
每個狀態形成一個子類,每個狀態只關心它的下一個可能狀態,從而無形中形成了狀態轉換的規則。如果新的狀態加入,只涉及它的前一個狀態修改和定義。
狀態轉換有幾個方法實現:一個在每個狀態實現next(),指定下一個狀態;還有一種方法,設定一個StateOwner,在StateOwner設定stateEnter狀態進入和stateExit狀態退出行爲。
狀態從一個方面說明了流程,流程是隨時間而改變,狀態是截取流程某個時間片。
相關文章:
參考資源:
the State and Stategy
How to implement state-dependent behavior
The state patterns