在狀態模式（state pattern）中，類的行為是基於它的狀態改變的。這種型別的設計模式屬於行為型模式。我們建立表示各種狀態的物件和乙個行為隨著狀態物件改變而改變的 context 物件。
大話設計模式中程傑老師給出的定義是，狀態模式：當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。
狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類中，可以把複雜的判斷邏輯簡化。當然，如果這個狀態判斷很簡單就沒有必要使用「狀態模式」了。
狀態模式結構圖如下：
結構**析：
1、state，抽象狀態類，定義乙個介面以封裝與context的乙個特定狀態相關的行為；
2、concretestate類，具體狀態類，每乙個子類實現乙個與context的乙個狀態相關的行為；
3、context類，維護乙個concretestate子類的例項，這個例項定義當前的狀態；
下面給出乙個運動員開始和結束運動的例項還具體看一下狀態模式的運用，類圖如下：
/** * 抽象狀態介面
*@author lmb
* */
public
inte***ce
state
package com.exercise.state;
/** * 狀態物件startstate
*@author lmb
* */
public
class
startstate
implements
state
public string tostring()
}
package com.exercise.state;
/** * 狀態物件stopstate
*@author lmb
* */
public
class
stopstate
implements
state
public string tostring()
}
package com.exercise.state;
/** * 行為隨著狀態物件改變而改變的context類
*@author lmb
* */
public
class
context
public state getstate()
public
void
setstate(state state)
}
package com.exercise.state;
public
class teststate
}
player is
in start state.
start state
player is
instop state.
stop state
使用場景：
當乙個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式。
缺點：
1、狀態模式的使用必然會增加系統類和物件的個數。
2、狀態模式的結構與實現都較為複雜，如果使用不當將導致程式結構和**的混亂。
3、狀態模式對」開閉原則」的支援並不太好，對於可以切換狀態的狀態模式，增加新的狀態類需要修改那些負責狀態轉換的源**，否則無法切換到新增狀態，而且修改某個狀態類的行為也需修改對應類的源**。
注意事項：在行為受狀態約束的時候使用狀態模式，而且狀態不超過 5 個。
大話設計模式 狀態模式
首先看一段 public class work else if hour 13 else if hour 17 else elseelse 當有很多條件判斷時，且很多的條件判斷後產生了很多的業務邏輯，雖然 可以正常執行，但是要修改某個邏輯，既整改邏輯流程也許就回發生改變，從而加大了維護時間的成本，並...
java 狀態模式（大話設計模式）
該模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。當然，如果這個判斷邏輯很簡單，那就沒必要用 狀態模式 了。互相組合 抽象狀態類 author administrator public abstract ...
《十二》讀《大話設計模式》之狀態模式
對於狀態模式，大話設計模式 是以人從上班到下班到加班的狀態來展開講述的。狀態模式其實就是某乙個物件在某個過程或者時間的乙個狀態記錄，但是這個狀態的順序不能發生變化，在程式設計方面可能要比其他模式稍微複雜點，請待我慢慢將來。本人喜歡用 來形象的講述原理，可能是因為對單純的看些理論的書有些反感或者無趣吧...