狀態模式的核心是封裝， 狀態的變更引起了行為的變更， 從外部看起來就好像這個物件對應的類發生了改變一樣。
● state——抽象狀態角色
介面或抽象類， 負責物件狀態定義， 並且封裝環境角色以實現狀態切換。
● concretestate——具體狀態角色
每乙個具體狀態必須完成兩個職責： 本狀態的行為管理以及趨向狀態處理， 通俗地說，就是本狀態下要做的事情， 以及本狀態如何過渡到其他狀態。
● context——環境角色
定義客戶端需要的介面， 並且負責具體狀態的切換。
context：定義客戶端感興趣的介面，並且維護乙個concretestate子類的例項，這個例項定義當前狀態；
state：定義乙個介面以封裝與context的乙個特定狀態相關的行為；
concretestate subclasses：每乙個子類實現乙個與context的乙個狀態相關的行為。
#include using● 結構清晰namespace
std;
class
context;
class
state
;class concretestatea : public
state
};class concretestateb : public
state
};class
context
void
request()
}void changestate(state *pstate)
private
: state *m_pstate;
};int
main()
避免了過多的switch...case或者if...else語句的使用， 避免了程式的複雜性,提高系統的可維護性。
● 遵循設計原則
很好地體現了開閉原則和單一職責原則， 每個狀態都是乙個子類， 你要增加狀態就要增加子類， 你要修改狀態， 你只修改乙個子類就可以了。
● 封裝性非常好
這也是狀態模式的基本要求， 狀態變換放置到類的內部來實現， 外部的呼叫不用知道類內部如何實現狀態和行為的變換。
狀態模式既然有優點， 那當然有缺點了。 但只有乙個缺點， 子類會太多， 也就是類膨脹。
● 行為隨狀態改變而改變的場景
這也是狀態模式的根本出發點， 例如許可權設計， 人員的狀態不同即使執行相同的行為結果也會不同， 在這種情況下需要考慮使用狀態模式。
● 條件、 分支判斷語句的替代者
在程式中大量使用switch語句或者if判斷語句會導致程式結構不清晰， 邏輯混亂， 使用狀態模式可以很好地避免這一問題， 它通過擴充套件子類實現了條件的判斷處理。
狀態模式適用於當某個物件在它的狀態發生改變時， 它的行為也隨著發生比較大的變化， 也就是說在行為受狀態約束的情況下可以使用狀態模式， 而且使用時物件的狀態最好不要超過5個。
設計模式 狀態模式
狀態模式 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況，把狀態的判斷邏輯轉移到表示不同狀態的一些列類當中，可以把複雜的判斷邏輯簡化。當乙個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行...
設計模式 狀態模式
1.概述 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。2.解決的問題 主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。3.模式中的角色 3.1 上下文環境 context 它定義了客...
設計模式 狀態模式
描述 允許物件在內部狀態改變時改變它的行為，物件看起來好像修改了它的類。主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。通常應用在有好多狀態的流程中。類圖 以下程式模擬糖果機器投幣取糖果的狀態流程。1.定義狀態...