状态模式的高效运用－2

状态机的实现好坏，往往是一个非常关键的问题。采用前面介绍的方式来实现有限状态机，往往只适用于状态比较少、消息处理、状态跃迁比较简单的情况；对于比较复杂的应用，这样做往往会导致状态之间紧密耦合，扩展不易。在这种代码中往往充斥着大量的状态扩展变量，并且杂散在各个偏僻角落，同时状态处理需要的数据一般而言对所有状态都是全局共享的，也就是说所有状态共享一个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的状态转换函数
    }