状态模式的高效运用_图文.docVIP

2005-8-29星期一 (Monday晴 状态模式是 GoF23个模式中最常用的之一,这篇小文不打算涉及方方面面的内容,只想 在状态模式的高效运用方面谈一下自己的心得体会。 状态模式是用来设计状态机的,因此下面的叙述中将它们等同理解。有关状态机设计方 面的书籍,我这里隆重推荐一本:《 Practical Statecharts in C/C++Quantum Programming for Embedded Systems 》 ,中文名叫做《嵌入式系统的微模块化程序设计-实用状态图 C/C++实 现》 ,北航出版的,作者是 Miro Samek 博士,长期从事嵌入式实时系统的开发,具有丰富的 经验。如果你想对状态机领域进行比较深入的研究,这本书绝对不容错过。 让我们先来看看比较 “ 古老 ” 的状态机实现,假设你还是用 C 语言。一般而言,我们用得 到状态机系统都可以称为事件(消息驱动系统,系统往往处于某个状态,等待外部的激励。 这些激励可以是外部的事件、定时器超时等等,系统收到这些事件后,进行相应的处理,然 后跃迁到新的状态(状态也可能不变继续等待下一个激励的到来,最后直到相应的事务处 理完毕为止。 典型的状态机实现中需要考虑几个要素:状态、消息(及其内容 、消息处理函数以及系 统上下文等。系统处于某个状态,收到某个消息后,解析出消息内容,然后调用相应的消息 处理函数进行处理,而消息处理函数往往会用到状态机的上下文数据,消息处理完毕系统会 跃迁到新的状态。 典型代码大致如下: switch (state { case STATE1: switch (msg { case MSG1: HandleMsg1(msgpara,context; nextstate(STATE2; break; case MSG2: HandleMsg2(msgpara,context; nextstate(STATE3; break; /*......*/ } case STATE2: switch (msg { case MSG3: HandleMsg3(msgpara,context; 2005-8-31星期三 (Wednesday晴 状态机的实现好坏,往往是一个非常关键的问题。采用前面介绍的方式来实现有限状态 机,往往只适用于状态比较少、消息处理、状态跃迁比较简单的情况;对于比较复杂的应用, 这样做往往会导致状态之间紧密耦合,扩展不易。在这种代码中往往充斥着大量的状态扩展 变量,并且杂散在各个偏僻角落,同时状态处理需要的数据一般而言对所有状态都是全局共 享的,也就是说所有状态共享一个 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,/*otherparameters*/{} //etc... }; 然后定义具体的状态子类,对消息各取所需。 class Stat