从接口的前置状态校验 到 状态模式的方法是否能执行 再 有限状态机(FSM)的事件校验 ,状态机

技术人人都是xx

技术设计金字塔 包含了状态设计文章

1. 传统写接口:

       1. 都需要校验下当前状态是否是预期状态中的之一. [预期中的状态都支持这个事件] 在代码中 if ( state == )

                    新增状态时,对散落在各地的代码修改.  附录1

             2. 通过 sql中预留expectStatus来实现

                   新增状态时,处理较好. 同状态机.

      新增状态时,需要

             1. 新增新的状态变更方法

             2. 对原来的各个状态变更,修改对应的expect值.

2. 但是到了状态机之后: 状态机唯一性, 一个handler主目标状态必须唯一.( 状态拆成成两个字段除外.)

2.1 状态机1.0 事件即静态方法

    只需要传递一个事件就好了.校验变成了 事件是否是当前状态支持的.[已经配置好,状态是否支持这个事件.].

    然后事件对应着方法, 一个状态有哪些方法,能否执行很方便. 

public class PayingOrderState implement OrderState { 
    public OrderState pay(Order order) {
        throw IllegalStateException("已经在支付中"); 
    }

   

    新增状态后,比较简单. 

        1. 在新的status类里实现各个事件就好了.

        2. 在原来的status实现新的事件.

    这两个要相等的前提条件是 : 故要求达到不同状态的事件不能相同. 

FSM

   F(S, E) -> (A, S')，即如果当前状态为S，接收到一个事件E，则执行动作A，同时状态转换为S‘。

    预先配置好状态和事件流转, 状态允许的事件,行为类实例,和状态. 详见

     

   基于Spring-statemachine的有限状态机(FSM)的介绍及示例 

    执行的时候. 调用状态机,传入事件和上下文信息即可.

   这个逻辑怎么证明? 计算机逻辑课上咨询.

2.2  事件对应的代码是动态配置的handler

        新增状态后,就需要对各个事件分析过去,是否需要新增一个handler. 本质上就是要遍历所有使用状态的地方,看看是否需要新增逻辑.

       有些时候,为了入口代码简单, 往往在内部对状态进行if else. 例如 都是入金, accept状态后的入金和

附录:

1. 复杂业务状态的处理：从状态模式到 FSM