在日常开发工作中, 我们在建模时会经常遇到实体在多个状态间进行变迁的问题， 比如：

一个订单的状态可能是 “已下单” , “已支付”, “取消”, “完成” 等，并且在满足一定的条件的情况下触发特定动作会发生实体的状态迁移。一般来说，实体的可能状态是有限的, 对于这类问题，我们一般称为FSM(Finite State Machine), 即有限状态机。举个以前项目的例子：

某种设备通过GPRS连接到控制中心, 并且通过接受控制中心的控制指令来改变自身的运行状态,为了达到这个目的， 设备的底层系统提供了控制设备的API:

现在要求上层编写设备管理程序, 其状态图如下：

这是一个典型的状态机实现的问题, 设备拥有多个可能的状态, 并且在特定状态下接受正确的指令后可以迁移到指令的目标状态,直观的看，状态机是一个有向图，状态为端点，操作为边， 一个状态端点在特定操作的驱动下迁移到另一个状态端点。

一份快速的实现

我们用伪代码来描述如下:

define state = shutdown;

do function start();

set state = started;

done;

同时,一个完整的状态变迁图告诉我们如下事实:

• 一个状态端点可以由哪些状态端点变迁而来
  
• 一个状态端点可以变迁到哪些状态端点而去
  

那么针对这个问题我们可以快速的给出如下的一份实现:

//获取接受到的命令类型

final EventTypeEnum eventType = event.eventType();

//获取接受到的命令内容

final byte[] cmd = event.getInstruction();

switch (eventType) {

//接收到设备启动指令

case BOOT:

switch (currentDeviceStatus) {

//当前状态为关闭状态, 允许启动

case STATUS_POWEROFF:

//获取设备底层API并调用

DeviceRuntime.getDevice().boot(cmd);

currentDeviceStatus =

DeviceStatus.STATUS_BOOTED;

return true;

default:

return false;

}

//接受到设备关闭指令

case POWEROFF:

switch (currentDeviceStatus) {

//当前设备状态为已配置, 允许执行

case STATUS_CONFIURED:

//当前设备状态为已启动, 允许执行

case STATUS_BOOTED:

//当前设备状态为已待机, 允许执行

case STATUS_STANDBY:

//当前设备状态为在网待机,允许执行

case STATUS_LINKED_STANDBY:

DeviceRuntime.getDevice().shutdown(cmd);

currentDeviceStatus =

DeviceStatus.STATUS_POWEROFF;

return true;

default:

return false;

}

//接收到设备激活指令

case ACTIVE:

//...

case CONFIGURE:

//...

case LINK:

//...

case OFFLINE:

//...

case STANDBY:

//...

default:

return false;

我们用2层的switch来约束特定源状态，特定操作，特定目标状态， 如果不考虑状态机的修改，这应该是一个不错的实现，正确，简洁，易读. 但是在应付变化这方面就显得比较无能为力, 原因在于，这个版本的实现缺少结构化的抽象，缺乏职责划分导致无法做到变化的隔离。

考虑一下, 如果我们新增加一个状态， 按照当前的实现, 我们需要做的事情是这样的：

• 了解新端点是那些边的目标端点
  
• 在外层switch中为每条指向新端点的边构造一个switch分支，在内层switch中为每
  
• 个源端点构建一个状态变迁实现
  
• 了解新增端点是那些原有端点的源
  
• 在外层switch中为每条指向原有端点的边构造一个switch分支，在每个内层switch中为新增端点建立一个状态变迁实现
  

改进后的实现

很明显，正确的完成这件事情并不容易，试想如果一个状态机包含几十个状态，上百个动作，一次要新增或删除数个节点，改动和测试的复杂度将非常高。

下面我们来改进上面的实现, 前面讲过, 一个状态端点在特定操作的驱动下迁移到另一个状态端点, 这是状态机的唯一行为模式,是稳定的, 不稳定的是新增状态时的前置约束,指令的新增以及状态的变化, 所以从大体上我们需要把稳定的行为和不稳定的行为进行隔离和抽象。

首先, 我们再来对一次状态变迁进行分析：

一次状态迁移必然包含如下要素：

• 迁移的事件类型是什么? 比如启动, 激活, 关闭等
  
• 迁移的原状态时什么? 比如 启动类型的迁移, 其原状态必须是已关闭
  
• 迁移结束后的状态是什么? 比如 启动类型的迁移, 其目标状态时已启动
  
• 迁移指令如何执行
  

如果我们从这个角度来进行抽象, 我们需要一个操作模型来封闭起始状态和指令的执行,那么我们首先来定义一个设备的操作：

public interface DeviceOperation {

/**

* 返回此操作代表的类型

* @return 操作代表的类型

*/

public EventTypeEnum operationType();

/**

* 声明设备在什么状态下允许执行此操作

* @return 操作可执行的设备状态

*/

public Set<DeviceStatus> avaliableStatus();

/**

* 声明如果此指令操作成功, 设备应该处于的下一个状态

* @return 设备的新状态

*/

public DeviceStatus nextStatus();

/**

* 执行指令操作

* @param cmd 指令数据

*/

public void doOperation(final byte[] cmd);

}

一个操作(边)有它自己的类型, 有执行指令的实现，有目标端点和源端点。所有的要素都有了， 我们可以这样描述一个具体实现

操作X -> "操作X的类型为 operationType() , 在当前状态为 avaliableStatus()之一时允许执行指令操作doOperation(#cmd#)， 成功执行后设备状态更改为nextStatus()"

由于指令模型再执行指令时向上表现为一致的行为方式, 而底层设备为不同指令提供了不同的API, 因此在真正执行指令操作的地方, 我们也需要进行抽象和适配(下图仅列出部分操作)：