从工作流状态机实践中总结状态模式使用心得

 作者：banq 发表时间：2003年12月07日 00:10 回复
原贴网址：http://www.jdon.com/jivejdon/thread/10981.html

 

状态模式好像是很简单的模式，正因为状态好像是个简单的对象，想复杂化实现设计模式就不是容易，误用情况很多。

我个人曾经设计过一个大型游戏系统的游戏状态机，游戏状态可以说是游戏设计的主要架构，但是由于系统过分复杂
和时间仓促，并没有真正实现状态模式。

目前在实现一个电子政务项目中，需要进行流程状态变化，在电子政务设计中，我发现，如果一开始完全按照工作流
规范开发，难度很大，它和具体项目实践结合无法把握，而且工作流规范现在有wfmc，还有bpml，选择也比较难。因
此，我决定走自创的中间道路。

因为，我需要做一个状态机API，或者说状态机框架，供具体系统调用：类如公文流转应用或信息发报送应用等。

好的状态模式必须做到两点：
1. 状态变化必须从外界其它逻辑划分出来。
2. 状态必须可方便拓展，对其它代码影响非常小。

要做到这两点，必须先明确状态变化机制，状态变化实际是由Event事件驱动的，可以认为是Event-condition-State，
在MVC模式一般是Event-condition-Action实现。状态模式需要封装的是Event-condition-State中的condition-State
部分。

清晰理解状态和流程的关系也非常重要，因为状态不是孤立的，可以说和流程是点和线的关系，状态从一个方面说明
了流程，流程是随时间而改变，状态是截取流程某个时间片。因此，必须明白使用状态模式实现状态机实际是为了更
好地表达和说明流程。

状态和流程以及事件的关系如下：

                 |Event___currentState__|______newState___

图中表示了是事件改变了流程的状态，在业务逻辑中，经常发生的是事件，如果不使用状态模式，需要在很多业务逻
辑处实现事件到状态判定和转换，这有很多危险性。

最大的危险是系统没有一个一抓就灵的主体结构，以那个游戏系统为例，在没有状态模式对状态提炼的情况下，状态
改变由每个程序员想当然实现，导致每个程序员开发的功能在整合时就无法调试，因为这个程序员可能不知道那个程
序员的代码在什么运行条件下改变了游戏状态，结果导致自己的代码无法运行。

这种现象实际上拒绝了项目管理的协作性，大大地拖延项目进度（程序员之间要反复商量讨论对方代码设计）。从这
一点也说明，一个好的架构设计是一个项目快速成功完成的基础技术保证，没有这个技术基础，再先进的项目管理手
段也是没有效率的，或者是笨拙的。

状态模式对于很多系统来说，确实是架构组成一个重要部分。

下面继续讨论如何实现一个好的状态模式，为了实现好的状态模式，必须在状态模式中封装下面两个部分：
1. 状态转换规则（行为）
2. 状态属性（属性）

状态转换行为有两种划分标准：
1. run和next两个行为，run是当前状态运行行为，next是指在Event参与下，几种可能转向的下一个状态。
2. stateEnter和stateExit， 状态进入和状态退出。

如果用进入一个个房间来表示状态流程的话， 第一种分析是只重视着“在房间里”和“如何转入下一个房间”，这两种行
为一旦确定，可以被反复使用，进而一个流程的状态切换可以全部表达出来。

第二中分析方法有所区别，只重视进入房间和离开房间这个两个行为，同样，这种模型也可以被反复利用在其它房间，
一个流程的状态切换也可以全部表达出来。

具体选择取决于你的需求，比如，如果你在进入一个状态开始，要做很多初始化工作，那么第二种模型就很适合。

状态变化都离不开一个主体对象，主体对象可以说包含状态变化（行为）和状态属性（属性），假设为StateOwner，
StateOwner有两个部分组成：Task/事情和状态。任何一个Task/事情都会对应一个状态。

这样，我们已经抽象出两个主要对象：状态State和StateOwner。

为了封装状态变化细节，我们可以抽象出一个状态机StateMachine来专门实现状态根据事情实现转换。

这样，客户端外界通过状态机可访问状态模式这个匣子。在实践中，外界客户端需要和状态机实现数据交换，我们把
它也分为两种：属性和行为。

其中属性可能需要外界告诉状态状态变化的主体对象Task，解决状态的主人问题，是谁的问题；行为可能是需要持久
化当前这个主体对象的状态到数据库。

这两种数据交换可以分别通过StateOwner和StateMachine与整个状态机实现数据交换，这样，具体状态和状态切换也
和外界实现了解耦隔离。

因此好的状态模式实现必须有下列步骤：
（1）将每个状态变成State的子类，实现每个状态对象化。
（2）在每个状态中，封装着进入下一个状态可能规则，这些规则是状态变化的核心，换句话说，统一了状态转换的规则。
具体可采取run和next这样的转换行为。

下面是一个子状态代码：

public class Running extends StateT{

public State next(Event e) throws InvalidStateException{    logger.debug(

Re: 从工作流状态机实践中总结状态模式使用心得 发表: 2005年12月28日 21:40 回复 chenyongguang 发表文章: 11/ 注册时间: 2005年12月26日 09:44 通过banq老师的多次指点，今天终于在前面介绍的思想和部分代码的基础上实现了一个非常简单的工作流状态机，是一个有关会议室申请的流程，在这里非常感谢banq老师和其他的jdon道友。但同时也对前面一个道友谈到的观点深有体会，就是状态太多了。（我设计了一个State,下面有许多具体子类，比如Committed,Passed,Finished之类），如下图。 有没有更好的方法？另外，比如公文发文流程，它一般有拟稿、核稿、批准、归档等状态，这些状态是不是又要重写？还是可以复用会议室申请的那个工作流状态机？也就是说可不可以抽象出一个一般工作流状态机，然后根据具体应用逻辑，在实例化成会议室申请状态机、公文发文状态机、物品领用状态机之类的？