状态机的实现好坏，往往是一个非常关键的问题。采用前面介绍的方式来实现有限状态机，往往只适用于状态比较少、消息处理、状态跃迁比较简单的情况；对于比较复杂的应用，这样做往往会导致状态之间紧密耦合，扩展不易。在这种代码中往往充斥着大量的状态扩展变量，并且杂散在各个偏僻角落，同时状态处理需要的数据一般而言对所有状态都是全局共享的，也就是说所有状态共享一个Context，数据很容易被不经意的破坏，维护这样的代码真是一个梦魇。我自己也写过不少这样的代码，最后给我的感觉就是我处在一张巨大的蜘蛛网中，使劲挣扎却看不到出路。。。。。。
David Harel－状态图的发明者，说过：
结果，高度复杂的行为已不能用简单的、“平面的”状态转换图来方便的描述。其根源在于不可管理的大量状态，它们可能导致无结构的和混乱的状态转换图。
为了解决这些问题，大家进行了各种尝试，最后由GoF总结成为著名的State状态模式。
State模式的实现有许多变体，这里介绍一种比较经典的实现，是基于委托和多态实现的。在这种实现中，具体状态表示为抽象状态类的子类，该抽象状态类规定了处理各事件（消息）的共同接口（每个事件对应一个虚方法），Context把所有事件委托给当前状态对象。注意，现在状态变成了状态对象，可以具有自己私有的状态数据，从封装性角度无疑提高了一步。当然可能所有状态都必须共享一些数据，那么这些数据可以放在Context中。这种实现要求如果增加状态，那么需要实现这个状态子类；如果增加事件，需要在抽象状态类中增加接口。
状态模式的主要优点可以总结如下：
将特定状态相关的行为局部化，并且将不同状态的行为分割开来。
（1）状态转换高效（重新赋值一个指针）。
（2）不需要枚举状态，因为Context委托所有事件给当前状态对象处理。
（3）不需要枚举事件，改由Context进行枚举
（4）状态转换显式化
等等。 下面就是一些示例代码：
首先声明一个抽象的状态类，声明了状态机所有消息处理接口。消息缺省不进行任何处理。
class Fsm;
class State {
public:
virtual void onMSG1 (Fsm *ctx) {}
virtual void onMSG2 (Fsm *ctx) {}
virtual void onMSG3 (Fsm *ctx, /*other parameters*/) {}
//etc...
};
然后定义具体的状态子类，对消息各取所需。
class State1 : public State {
public:
virtual void onMSG1 (Fsm *ctx);
virtual void onMSG2 (Fsm *ctx);
};
class State2 : public State {
public:
virtual void onMSG3 (Fsm *ctx);
};
接着定义状态机类，也是所有状态对象的Context。
class Fsm {
friend class State1; //别忘了申明成友元
friend class State2;
//...
static State1 myState1; //静态的就OK，因为可能存在多个状态机，状态对象本身可以共享
static State2 myState2;
//...
State *myState; //当前状态对象指针，所有消息都委托给它处理
public:
//...
void onMSG1 () {myState->onMSG1();}
void onMSG2 () {myState->onMSG2();}
//...
void tran (State *targetState) {myState = targetState;} //状态转换函数，就是指针的转换
};
void State1::onMSG1 (Fsm *ctx)
{
//do something
ctx->tran (&Fsm::myState2); //调用Context的状态转换函数
}
