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

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

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

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

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

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

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

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

|Event
___currentState__|______newState___

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

最大的危险是系统没有一个一抓就灵的主体结构，以那个游戏系统为例，在没有状态模式对状态提炼的情况下，状态
改变由每个程序员想当然实现，导致每个程序员开发的功能在整合时就无法调试，因为这个程序员
上一页12 3 下一页

上一篇：流程的角色观及其管理
下一篇：提速企业流程——浅谈工作流管理系统