每個人、事物在不同的狀態下會有不同表現（動作），而一個狀態又會在不同的表現下轉移到下一個不同的狀態（State）。最簡單的一個生活中的例子就是：地鐵入口處，如果你放入正確的地鐵票，門就會打開讓你通過。在出口處也是驗票，如果正確你就可以 ok，否則就不讓你通過（如果你動作野蠻，或許會有報警（Alarm），：））。
有限狀態自動機（FSM）也是一個典型的狀態不同，對輸入有不同的響應（狀態轉移）。
通常我們在實現這類系統會使用到很多的 Switch/Case 語句，Case 某種狀態，發生什么動作，Case 另外一種狀態，則發生另外一種狀態。但是這種實現方式至少有以下兩個問題：
當狀態數目不是很多的時候，Switch/Case 可能可以搞定。但是當狀態數目很多的時候（實際系統中也正是如此），維護一大組的 Switch/Case 語句將是一件異常困難并且容易出錯的事情。
狀態邏輯和動作實現沒有分離。在很多的系統實現中，動作的實現代碼直接寫在狀態的邏輯當中。這帶來的后果就是系統的擴展性和維護得不到保證。
狀態模式就是被用來解決上面列出的兩個問題的，在狀態模式中我們將狀態邏輯和動作實現進行分離。當一個操作中要維護大量的 case 分支語句，并且這些分支依賴于對象的狀態。狀態模式將每一個分支都封裝到獨立的類中。
狀態模式典型的結構圖為：
狀態模式的實現
代碼片斷 1：State.h
//state.h#ifndef _STATE_H_#define _STATE_H_class Context; //前置聲明class State{ public: State(); virtual ~State(); virtual void OperationInterface(Context* ) = 0; virtual void OperationChangeState(Context*) = 0; protected: bool ChangeState(Context* con,State* st); private: //bool ChangeState(Context* con,State* st);};class ConcreteStateA:public State{ public: ConcreteStateA(); virtual ~ConcreteStateA(); virtual void OperationInterface(Context* ); virtual void OperationChangeState(Context*); protected: private:};class ConcreteStateB:public State{ public: ConcreteStateB(); virtual ~ConcreteStateB(); virtual void OperationInterface(Context* ); virtual void OperationChangeState(Context*); protected: private:};#endif //~_STATE_H_代碼片斷 2：State.cpp
//State.cpp#include "State.h"#include "Context.h"#include <iostream>using namespace std;State::State(){}State::~State(){}void State::OperationInterface(Context* con){ cout<<"State::.."<<endl;}bool State::ChangeState(Context* con,State* st){ con->ChangeState(st); return true;}void State::OperationChangeState(Context* con){}///ConcreteStateA::ConcreteStateA(){}ConcreteStateA::~ConcreteStateA(){}void ConcreteStateA::OperationInterface(Context* con){ cout<<"ConcreteStateA::OperationInterface ......"<<endl;}void ConcreteStateA::OperationChangeState(Context* con){ OperationInterface(con); this->ChangeState(con,new ConcreteStateB());}///ConcreteStateB::ConcreteStateB(){}ConcreteStateB::~ConcreteStateB(){}void ConcreteStateB::OperationInterface(Context* con){ cout<<"ConcreteStateB::OperationInterface......"<<endl;}void ConcreteStateB::OperationChangeState(Context* con){ OperationInterface(con); this->ChangeState(con,new ConcreteStateA());}代碼片斷 3：Context.h
//context.h#ifndef _CONTEXT_H_#define _CONTEXT_H_class State;/*****/class Context{ public: Context(); Context(State* state); ~Context(); void OprationInterface(); void OperationChangState(); protected: private: friend class State; //表明在 State 類中可以訪問 Context 類的 private 字段 bool ChangeState(State* state); private: State* _state;};#endif //~_CONTEXT_H_代碼片斷 4：Context.cpp
//context.cpp#include "Context.h"#include "State.h"Context::Context(){}Context::Context(State* state){ this->_state = state;}Context::~Context(){ delete _state;}void Context::OprationInterface(){ _state->OperationInterface(this);}bool Context::ChangeState(State* state){ ///_state->ChangeState(this,state); this->_state = state; return true;}void Context::OperationChangState(){ _state->OperationChangeState(this);}代碼片斷 5：main.cpp
//main.cpp#include "Context.h"#include "State.h"#include <iostream>using namespace std;int main(int argc,char* argv[]){ State* st = new ConcreteStateA(); Context* con = new Context(st); con->OperationChangState(); con->OperationChangState(); con->OperationChangState(); if (con != NULL) delete con; if (st != NULL) st = NULL; return 0;}代碼說明：狀態模式在實現中，有兩個關鍵點：
1.將狀態聲明為 Context 的友元類（friend class），其作用是讓狀態模式訪問 Context的 protected 接口 ChangeSate（）。
狀態及其子類中的操作都將 Context*傳入作為參數，其主要目的是狀態類可以通過這個指針調用 Context 中的方法（在本示例代碼中沒有體現）。這也是狀態模式和 Strategy模式的最大區別所在。
2.運行了示例代碼后可以獲得以下的結果：連續 3 次調用了 Context 的 OprationInterface（）因為每次調用后狀態都會改變（A－B－A），因此該動作隨著 Context 的狀態的轉變而獲得了不同的結果。
關于State模式的一些需要注意的地方
這個模式使得軟件可以在不同的state下面呈現出完全不同的特征
不同的theme使得相同的元素呈現出不同的特點
不同的state下面相同的操作產生不同的效果
不同的狀態對相同的信息產生不同的處理
這個模式使得操作的state邏輯更加的清楚，省去了無數的state判斷，而state的擴展性和可維護性和執行效率也大幅度的上升。關于state，有如下幾點要注意的地方：
1.所有的state應該被一個類（State Manager Class）管理:
state之間的跳轉和轉換是非常復雜的，有時一些state可能要跳轉的目標state有幾十個，這個時候我們需要一個管理類（State Manager ）來統一的管理這些state的切換，例如目標state的初始化和申請跳轉state的結束處理，以及一些state間共享數據的存儲和處理。與其稱這個Manager 為管理類，不如說是一個中間類，它實現了state之間的解隅，使得各個state之間不比知道target state的具體信息，而只要向Manager申請跳轉就可以了。使得各個state的模塊化更好，更加的靈活
2.所有的state都應該從一個state基類繼承:
既然state要教給一個manager來管理，那么自然的，這些state都應該從一個父類繼承下來，這樣manager并不需要知道很多子類的信息，一個最單純的manager只要只要管理一個這樣的基類的指針就可以了。另外，我們還可以統一的把state的一些共有的屬性放在這里
3.state應該實現為一個singleton:
state并不需要總是被申請，這樣可能會造成管理上的混亂，state資源的申請也不應該可以任意進行，事實上，state的申請權限應該只有 Manager才有，并且有且只有一次。在這樣的情況下，state的構造函數似乎應該被聲明為protected or private ，而Manager應該被聲明為state的友元，但是友元被看成是破壞類的封裝性的一種做法，這一點上，我很矛盾，所以在這一條上我只能采取一種漠視的態度。
4.應該做一個state么？這是一個問題：
state可以說是if-else的一種替代品，極端的情況下面state可以讓你的程序中if-else程序塊消失得無影無蹤，但是，這并不是銀彈。state對于狀態可預知的情況下非常有效，但是對于state不可預知，或者相似的state數量太多。過多的state會造成class的粒度過細，程序反而不簡潔。在這樣的情況下，你應該考慮使用if-else程序塊來替代state。
例如：
有這樣的一個程序，它可以生成任意形狀的多邊形，而多邊形的各個節點是可以移動的，問題就來了。
我并不知道用戶將要使用多少個節點的多邊形，因此我無法的創建那么多相應的state來使得這樣一個程序正常工作。state大多數都是確定的，對于不確定的，state似乎無能為力，例如此例
一種解決方法是我利用Manager傳遞給state一個state參數，讓state有機會知道用戶的操作意圖，在這個例子里面是讓state知道用戶打算操作某一個節點，而state根據這個state參數來處理用戶的操作，比如說，state得到的是用戶操作的某一個點的index ,而state只要寫
points[index].moveTo(points[index].getX()+offset_x , points[index].getY()+offset_y)；
就可以，從而避免了state過多出現的問題。
新聞熱點
疑難解答
圖片精選
