可能不知道那个程
序员的代码在什么运行条件下改变了游戏状态，结果导致自己的代码无法运行。

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

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

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

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

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

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

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

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

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

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

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

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

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