状态机使用小结

背景

最近做发票的开具和冲销业务,其中有N多状态。于是想到了状态机模式,减少条件判断,让业务逻辑更清晰。回头增加或者减少状态,自己也能快速建立全局视图。理想很丰满,现实很骨感。

选型之路

作为Java开发,首先想到的是Spring家族的状态机,毕竟Spring够强大。一顿操作运行起来之后,发现得先整理自己的基本预期和诉求,如下:

  1. 业务对象本身有个状态字段,状态机每次基于该字段做初始化;
  2. 业务对象所能接收的事件,其字段内容应该可轻松扩展;
  3. 状态转换过程中的事务与业务上下文强一致;

对应到Spring State Machine,后面简称SSM。

  1. 初始化。SSM是基于全局状态机。何为全局状态机,即状态机初始化之后,状态机保持所有节点和边的对应的对象,服务于后续具体的状态转换。官方文档也提到属于重量级对象,建议全局唯一。也正式这个原因,在使用过程中存在并发问题,使用不当可能导致死锁。状态转换完成后,需要实现特定的持久化接口完成状态机的状态保存。
  2. 事件。事件是基于枚举的和注解的,这条是最狠的。枚举的内容,不能修改。也就意味着业务事件只有事件类型一个可变参数。
  3. 至于状态迁移暴露出的各种事件接口,首先不得不说非常强大,但是如果只关注状态转换并触发事件,那么有很多都用不上。
  4. 事务边界难以控制,因为内部实现有看不见的异步任务。

小结下SSM,有点儿类似于一个状态机引擎,偏重量级,事件对象表示不够丰富,事务控制个人水平原因吧不敢保证。

工期原因就自己开发,参考Java的状态模式,定义StateContext和State。每个State只关注当前状态,支持的事件,以及对应事件的业务逻辑。操作步骤如下

  1. 先来一发状态图说清楚状态和转换事件,个人用VSCode中的markdown插件完成;
  2. 再来一个状态业务表,说明状态A,收到事件时执行的业务;
  3. YY运行一遍,就完成了设计;
  4. 优化一波,各个状态中执行的业务差别在参数不同,提一个状态抽象父类作为状态模板。每个状态增加如下方法,是否支持某个事件,该状态支持的所有事件。

业务整合

到这里,状态机的壳子就完成了,发现另外一个问题。什么业务放在状态Service中,什么业务放在普通Service中,两者的关系是什么。显然,状态业务应该放在状态Service。个人认为,状态业务在普通Service之下,应该嵌套其中,因为对外不关心你是怎么实现的。如果mapper是0层,Service是1层,那状态服务就是0.5层。这个问题解决之后,事务控制也就好办了。

测试与发现

  1. 使用状态机以后,测试的内容分为状态本身和具体业务,也就是模板类中的方法。测试状态机就像测试纷繁复杂的If分支,不过状态机的分支可轻易穷尽,If分支我是没有信心的。如果愿意把所有的状态转换日志收集起来,还可以可视化出整个状态转换过程。

反思与小结

  1. 设计模式还是很强大的,需要掌握的不是细节,而是整体的脉络。需要的时候,细节再研究。
  2. 也许SSM只是希望输入一个状态和事件得到一个结果状态,是我在用法上有问题。毕竟在状态中执行业务逻辑也是有耦合的。理想的应该是通过事件监听的方式松耦合,这是从SSM中学习到的。

你可能感兴趣的:(笔记)