摘要：一般来说，实体的可能状态是有限的, 在满足一定的条件的情况下触发特定动作会发生实体的状态迁移。对于这类问题，我们一般称为FSM(Finite State Machine), 即有限状态机。本文分享一个有限状态机的java实现，以及使用DSL实现的通用化描述。 在日常开发工作中, 我们在建模时会经常遇到实体在多个状态间进行变迁的问题， 比如： 一个订单的状态可能是 “已下单” , “已支付”, “取消”, “完成” 等，并且在满足一定的条件的情况下触发特定动作会发生实体的状态迁移。一般来说，实体的可能状态是有限的, 对于这类问题，我们一般称为FSM(Finite State Machine), 即有限状态机。举个以前项目的例子： 某种设备通过GPRS连接到控制中心, 并且通过接受控制中心的控制指令来改变自身的运行状态,为了达到这个目的， 设备的底层系统提供了控制设备的API: 现在要求上层编写设备管理程序, 其状态图如下： 这是一个典型的状态机实现的问题, 设备拥有多个可能的状态, 并且在特定状态下接受正确的指令后可以迁移到指令的目标状态,直观的看，状态机是一个有向图，状态为端点，操作为边， 一个状态端点在特定操作的驱动下迁移到另一个状态端点。 一份快速的实现 我们用伪代码来描述如下:
同时,一个完整的状态变迁图告诉我们如下事实:
那么针对这个问题我们可以快速的给出如下的一份实现:
我们用2层的switch来约束特定源状态，特定操作，特定目标状态， 如果不考虑状态机的修改，这应该是一个不错的实现，正确，简洁，易读. 但是在应付变化这方面就显得比较无能为力, 原因在于，这个版本的实现缺少结构化的抽象，缺乏职责划分导致无法做到变化的隔离。 考虑一下, 如果我们新增加一个状态， 按照当前的实现, 我们需要做的事情是这样的：
改进后的实现 很明显，正确的完成这件事情并不容易，试想如果一个状态机包含几十个状态，上百个动作，一次要新增或删除数个节点，改动和测试的复杂度将非常高。 下面我们来改进上面的实现, 前面讲过, 一个状态端点在特定操作的驱动下迁移到另一个状态端点, 这是状态机的唯一行为模式,是稳定的, 不稳定的是新增状态时的前置约束,指令的新增以及状态的变化, 所以从大体上我们需要把稳定的行为和不稳定的行为进行隔离和抽象。 首先, 我们再来对一次状态变迁进行分析： 一次状态迁移必然包含如下要素：
如果我们从这个角度来进行抽象, 我们需要一个操作模型来封闭起始状态和指令的执行,那么我们首先来定义一个设备的操作：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
