【设计模式】订单状态流传中的状态机与状态模式

这篇具有很好参考价值的文章主要介绍了【设计模式】订单状态流传中的状态机与状态模式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1. 前言

状态模式一般是用在对象内部的状态流转场景中,用来实现状态机

什么是状态机呢?
状态机是对状态转移的抽象,由事件状态动作组成,事件有时候也被称为转移事件或者转移,当事件触发时,可以将状态由一个状态变更为另一个状态,并执行动作。其中,事件和状态是必须存在的,动作可以不要。

下面是一张状态图,表达的就是一个状态机的模型。
【设计模式】订单状态流传中的状态机与状态模式,# 设计模式,架构与设计,设计模式,状态模式,软件工程
通俗来讲,就是对状态的变更做了一定的限制,不能随意的修改状态,而是只有处于某个特定的状态时,才能变更到另一个特定的状态。

2.状态模式

状态模式将状态抽象成一个个的状态对象,状态机当前持有某个状态对象,就表示当前的状态机处于什么状态。
然后将事件处理为一个个的方法,每个方法中会操作状态机修改状态,有需要的情况下,在修改状态的同时还可以执行某些动作。

把通用部分提取出来后,可以得到这样一个通用类图:
【设计模式】订单状态流传中的状态机与状态模式,# 设计模式,架构与设计,设计模式,状态模式,软件工程

可以看到上面的StateMachineState关系是双向的,这是因为状态机需要持有状态对象来表示当前状态,以及通过当前的状态对象中的方法进行状态的流转,而流转的结果需要重新set到状态机中,又要求State必须持有状态机对象。
当然,这里StateStateMachine的关系也可以通过依赖来表示。

2.1.订单状态流转案例

假设现在有一个商品订单的状态流转需求,状态图如下:
【设计模式】订单状态流传中的状态机与状态模式,# 设计模式,架构与设计,设计模式,状态模式,软件工程
这里没有加退款的状态,后续的拓展例子上会加上,用这种方式来体验状态模式的拓展性。

我们拿着这个图的时候,可以简单的在脑海里面过一遍如果通过if/else或者switch来做,应该要怎么写,后续如果想把退款的状态加入进去又该怎么拓展,这种方式应该大家都会,就不在这里赘述了。

接下来,就一步步的通过状态模式来实现这么一个状态机。

2.1.1.状态枚举定义

定义状态枚举主要是为了统一状态常量,因为订单是需要落库的,我们在持久化到数据库时,不能把状态对象保存进去,所以会涉及到状态常量与状态对象的互相转换。定义的枚举如下:

import lombok.Getter;

@Getter
public enum OrderStateEnum {
    WAIT_PAYMENT(1, "待支付"),
    WAIT_DELIVER(2, "待发货"),
    WAIT_RECEIVE(3, "待收货"),
    RECEIVED(4, "已收货"),
    CANCEL(5, "已取消");

    private final int state;
    private final String desc;

    OrderStateEnum(int state, String desc) {
        this.state = state;
        this.desc = desc;
    }

    public int getState() {
        return state;
    }

    public String getDesc() {
        return desc;
    }
}

2.1.2.状态接口与实现

先上代码:

public interface OrderState {

    OrderStateEnum orderStateType();
    
    default void pay(OrderStateMachine stateMachine) {
        System.out.println("|--当前订单状态不支持支付,已忽略");
    }
    default void cancel(OrderStateMachine stateMachine) {
        System.out.println("|--当前订单状态不支持取消,已忽略");
    }
    default void deliver(OrderStateMachine stateMachine) {
        System.out.println("|--当前订单状态不支持发货,已忽略");
    }
    default void receive(OrderStateMachine stateMachine) {
        System.out.println("|--当前订单状态不支持收货,已忽略");
    }
}

接口中定义的pay,cancel等方法就是事件,供子类进行实现,相信大家也发现了,这些事件没有定义成抽象方法,而是通过default定义成了一个实例方法。不太清楚为什么的同学,可以先思考一下为什么要这么定义。

其实这么定义的好处是各个状态子类只需要实现自己需要的方法,而不用把所有的方法都实现一遍,这种做法在Spring中也比较常见,在JDK8之前通常是用xxxWrapper来实现的,JDK8之后就重构为直接使用default方法来实现了。

举个例子:后续如果需要加入退款状态,接口中也会新增一个提交退款的事件,在各个子类中,选择需要实现提交退款事件的状态子类进行重写即可,而不需要所有的子类都重写。


有多少个状态,就有多少个实现类,并按照上面的状态图,在对应的状态中实现自己需要的事件。

  • 待支付状态:有支付和取消两种事件
    public class WaitPaymentState implements OrderState {
    
        @Override
        public OrderStateEnum orderStateType() {
            return OrderStateEnum.WAIT_PAYMENT;
        }
    
        @Override
        public void pay(OrderStateMachine stateMachine) {
            stateMachine.setCurrentState(new WaitDeliverState());
        }
    
        @Override
        public void cancel(OrderStateMachine stateMachine) {
            stateMachine.setCurrentState(new CancelState());
        }
    }
    
  • 待发货状态:有发货事件
    public class WaitDeliverState implements OrderState {
    
        @Override
        public OrderStateEnum orderStateType() {
            return OrderStateEnum.WAIT_DELIVER;
        }
    
        @Override
        public void deliver(OrderStateMachine stateMachine) {
            stateMachine.setCurrentState(new WaitReceiveState());
        }
    }
    
  • 待收货状态:有收货事件
    public class WaitReceiveState implements OrderState {
    
        @Override
        public OrderStateEnum orderStateType() {
            return OrderStateEnum.WAIT_RECEIVE;
        }
    
        @Override
        public void receive(OrderStateMachine stateMachine) {
            stateMachine.setCurrentState(new ReceivedState());
        }
    }
    
  • 已收货状态:状态结束点,没有其他事件
    public class ReceivedState implements OrderState {
    
        @Override
        public OrderStateEnum orderStateType() {
            return OrderStateEnum.RECEIVED;
        }
    
    }
    
  • 取消状态:状态结束点,没有其他事件
    public class CancelState implements OrderState {
    
        @Override
        public OrderStateEnum orderStateType() {
            return OrderStateEnum.CANCEL;
        }
    }
    

2.1.3.状态机

状态机中需要持有当前状态对象,同时需要把状态接口中的事件同步定义到状态机中,以便外部业务对象调用。
除此之外,状态枚举常量与状态对象之间的映射关系也可以直接配置在当前状态机中,功能更加内聚。

public class OrderStateMachine {

    public static final Map<OrderStateEnum, OrderState> ORDER_STATE_MAP = new HashMap<>();

    static {
        ORDER_STATE_MAP.put(OrderStateEnum.WAIT_PAYMENT, new WaitPaymentState());
        ORDER_STATE_MAP.put(OrderStateEnum.WAIT_DELIVER, new WaitDeliverState());
        ORDER_STATE_MAP.put(OrderStateEnum.WAIT_RECEIVE, new WaitReceiveState());
        ORDER_STATE_MAP.put(OrderStateEnum.RECEIVED, new ReceivedState());
        ORDER_STATE_MAP.put(OrderStateEnum.CANCEL, new CancelState());
    }

    private OrderState currentState;

    public OrderStateMachine(OrderStateEnum orderStateEnum) {
        this.currentState = ORDER_STATE_MAP.get(orderStateEnum);
    }

    public OrderState getCurrentState() {
        return currentState;
    }

    public void setCurrentState(OrderState currentState) {
        this.currentState = currentState;
    }

    void pay() {
        currentState.pay(this);
    }

    void deliver() {
        currentState.deliver(this);
    }

    void receive() {
        currentState.receive(this);
    }

    void cancel() {
        currentState.cancel(this);
    }

}

2.1.4.测试

做一下状态机的测试,由于打印的日志重复度很高,这里取了个巧,将函数作为参数封装了一下:

public class OrderService {

    public static void main(String[] args) {
        OrderStateMachine stateMachine = new OrderStateMachine(OrderStateEnum.WAIT_DELIVER);

        invoke(stateMachine::pay, "用户支付", stateMachine);
        invoke(stateMachine::deliver, "商家发货", stateMachine);
        invoke(stateMachine::receive, "用户收货", stateMachine);
        invoke(stateMachine::cancel, "取消支付", stateMachine);
    }

    public static void invoke(Runnable runnable, String desc, OrderStateMachine stateMachine) {
        System.out.println(desc + "前订单状态: " + stateMachine.getCurrentState().orderStateType().getDesc());
        runnable.run();
        System.out.println(desc + "后订单状态: " + stateMachine.getCurrentState().orderStateType().getDesc());
        System.out.println("------------------");
    }
}

待发货作为状态常量创建了一个状态机,状态机当前的状态就是待发货,下面的四个调用中,第1,4个是不会改变状态的,第2,3个会改变状态,下面以执行结果来验证猜测:

用户支付前订单状态: 待发货
|--当前订单状态不支持支付,已忽略
用户支付后订单状态: 待发货
------------------
商家发货前订单状态: 待发货
商家发货后订单状态: 待收货
------------------
用户收货前订单状态: 待收货
用户收货后订单状态: 已收货
------------------
取消支付前订单状态: 已收货
|--当前订单状态不支持取消,已忽略
取消支付后订单状态: 已收货
------------------

2.2.退款状态的拓展

通过状态模式来实现状态机,看重的就是它带来的拓展性和易维护性,所以在原有的基础上,加上退款的事件和状态,一起看看需要做些什么事。

2.2.1.代码拓展

下面是加入了退款的状态图:
【设计模式】订单状态流传中的状态机与状态模式,# 设计模式,架构与设计,设计模式,状态模式,软件工程
通过状态图可以看到,需要加入:

  • 两个状态:退款中已退款
  • 两个事件:申请退款确认退款
  • 原有状态拓展:待发货、待收货、已收货 3个状态中都需要引入申请退款事件

综上,一步一步的拓展代码:

  • 第一步:拓展枚举常量
    public enum OrderStateEnum {
        WAIT_PAYMENT(1, "待支付"),
        WAIT_DELIVER(2, "待发货"),
        WAIT_RECEIVE(3, "待收货"),
        RECEIVED(4, "已收货"),
        CANCEL(5, "已取消"),
        REFUNDING(6, "退款中"),
        REFUNDED(7, "已退款"),
        ;
    	// 省略后续代码……
    }
    
  • 第二步:拓展状态接口
    public interface OrderState {
        // 省略已有代码……
    
        default void refund(OrderStateMachine stateMachine) {
            System.out.println("|--当前订单状态不支持退款,已忽略");
        }
    
        default void confirmRefund(OrderStateMachine stateMachine) {
            System.out.println("当前订单状态不支持确认退款,已忽略");
        }
    }
    
  • 第三步:新增两个状态,退款中已退款
public class RefundingState implements OrderState {

    @Override
    public OrderStateEnum name() {
        return OrderStateEnum.REFUNDING;
    }

    @Override
    public void confirmRefund(OrderStateMachine stateMachine) {
        stateMachine.setCurrentState(new RefundedState());
    }
}
public class RefundedState implements OrderState {

    @Override
    public OrderStateEnum name() {
        return OrderStateEnum.REFUNDED;
    }
}
  • 第四步:拓展原有状态,待发货待收货已收货
public class WaitDeliverState implements OrderState {
    // 省略已有代码……
    
    @Override
    public void refund(OrderStateMachine stateMachine) {
        stateMachine.setCurrentState(new RefundingState());
    }
}
public class WaitReceiveState implements OrderState {
    // 省略已有代码……
    
    @Override
    public void refund(OrderStateMachine stateMachine) {
        stateMachine.setCurrentState(new RefundingState());
    }

}
public class ReceivedState implements OrderState {
    // 省略已有代码……

    @Override
    public void refund(OrderStateMachine stateMachine) {
        stateMachine.setCurrentState(new RefundingState());
    }

}
  • 第五步:拓展状态机
public class OrderStateMachine {

    public static final Map<OrderStateEnum, OrderState> ORDER_STATE_MAP = new HashMap<>();

    static {
          // 省略已有状态……
        ORDER_STATE_MAP.put(OrderStateEnum.REFUNDING, new RefundingState());
        ORDER_STATE_MAP.put(OrderStateEnum.REFUNDED, new RefundedState());
    }

    // 省略已有方法……

    void refund() {
        currentState.refund(this);
    }

    void confirmRefund() {
        currentState.confirmRefund(this);
    }
}

2.2.2.测试

在上面的代码中可以看到,都是在对配置进行追加,而没有对原有的逻辑做任何的修改,然后写一个测试:

public class OrderService {

    public static void main(String[] args) {
        OrderStateMachine stateMachine = new OrderStateMachine(OrderStateEnum.WAIT_DELIVER);

        invoke(stateMachine::pay, "用户支付", stateMachine);
        invoke(stateMachine::deliver, "商家发货", stateMachine);
        invoke(stateMachine::receive, "用户收货", stateMachine);
        invoke(stateMachine::cancel, "取消支付", stateMachine);
        invoke(stateMachine::refund, "申请退款", stateMachine);
        invoke(stateMachine::confirmRefund, "确认退款", stateMachine);
    }

    public static void invoke(Runnable runnable, String desc, OrderStateMachine stateMachine) {
        System.out.println(desc + "前订单状态: " + stateMachine.getCurrentState().orderStateType().getDesc());
        runnable.run();
        System.out.println(desc + "后订单状态: " + stateMachine.getCurrentState().orderStateType().getDesc());
        System.out.println("------------------");
    }

}

查看日志,是否触发退款:

用户支付前订单状态: 待发货
|--当前订单状态不支持支付,已忽略
用户支付后订单状态: 待发货
------------------
商家发货前订单状态: 待发货
商家发货后订单状态: 待收货
------------------
用户收货前订单状态: 待收货
用户收货后订单状态: 已收货
------------------
取消支付前订单状态: 已收货
|--当前订单状态不支持取消,已忽略
取消支付后订单状态: 已收货
------------------
申请退款前订单状态: 已收货
申请退款后订单状态: 退款中
------------------
确认退款前订单状态: 退款中
确认退款后订单状态: 已退款
------------------

2.3.小结

从上面的代码可以看到,通过状态模式可以很轻松的对状态进行拓展。

不过上面的例子中没有对状态机中的动作进行实现,其实动作和状态转换的逻辑放在一起就可以了,即通过事件(方法调用) 可以变更状态,同时也能够触发对应的动作。

此外,代码中只是状态机的流程,实际的开发中应该将状态机关联到对应的业务实体中,通过业务实体的实时状态来创建状态机,在完成状态流转之后再将状态更新到业务实体中。

3.总结

本篇主要讲述了如何通过状态模式来实现一个状态机。状态模式的实现,代码结构清晰(相对于if/else,switch)拓展性强,同时也起到了良好的封装效果(状态在状态机内部流转,业务流程不需要关心状态到底是怎么流转的)。

当然缺点就是类膨胀问题,类会比较多,如果状态非常复杂的情况下,也可以采取其他办法来实现状态机,例如查表法。

总之,要分析并实现一个业务流程中的状态流转的时候,先画出状态图,以状态图为指导来选择状态机的实现方式即可,在状态相对不那么复杂的情况下,可以优先考虑使用状态模式。

附:《【UML建模】状态图(State Machine Diagram)》文章来源地址https://www.toymoban.com/news/detail-657998.html

到了这里,关于【设计模式】订单状态流传中的状态机与状态模式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 设计模式-状态模式

    一个对象有状态变化 每次状态变化都会触发一个逻辑 不能总是用 if else 来控制 交通信号灯不同颜色的变化 传统UML类图 简化后的UML类图 有限个状态、以及在这些状态之间的变化 如交通信号灯 使用开源lib:javascript-state-machine github.com/jakesgordon/javascript-state-machine 有限状态机

    2024年02月07日
    浏览(42)
  • 设计模式_状态模式

    介绍 设计模式 定义 案例 问题堆积在哪里 解决办法 状态模式 一个对象 状态可以发生改变 不同的状态又有不同的行为逻辑 游戏角色 加载不同的技能 每个技能有不同的:攻击逻辑 攻击范围 动作等等 1 状态很多 2 每个状态有自己的属性和逻辑 每种状态单独写一个类 角色需要

    2024年02月06日
    浏览(36)
  • 设计模式(18):状态模式

    用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题 环境类(Context): 环境类中维护一个State对象,它定义了当前的状态,并委托当前状态处理一些请求; 抽象状态类(State): 用于封装对象的一个特定状态所对应的行为; 具体状态类(ConcreteState): 实现了抽象状态类

    2024年04月09日
    浏览(39)
  • 【前端设计模式】之状态模式

    在前端开发中,我们经常需要处理复杂的应用状态。这时候,状态模式就能派上用场了。状态模式允许我们根据不同的状态来改变对象的行为,从而实现优雅地管理应用状态。 状态模式具有以下特性: 状态(State):定义了对象在特定条件下所处的行为和属性。 上下文(C

    2024年01月20日
    浏览(44)
  • 设计模式之状态模式笔记

    记录下学习设计模式-状态模式的写法。JDK使用版本为1.8版本。 意图 :允许一个对象在其内部状态改变时改变它的行为。 结构 : 其中: Context(上下文)定义客户感兴趣的接口;维护一个ConcreteState子类的实例,这个实例定义当前状态。 State(状态)定义一个接口以封装与Context的一个

    2024年02月10日
    浏览(55)
  • 设计模式再探——状态模式

    最近产品中有这样的业务需求,不同时间(这里不是活动的执行时间,而是活动的执行时刻)展示不同的活动; 要求还是需要后续会由N种活动扩充进来,并且扩充的时候还得达到复用之前活动中的一些属性和方法。 结合这样的需求,再探状态模式,豁然开朗,于是乎总结分享

    2024年02月16日
    浏览(35)
  • 行为型设计模式——状态模式

    状态模式是比较简单的设计模式,它的主要作用是减少代码中大量的 if-else 或者 switch-case 等逻辑判断(俗称屎山)。它将每个状态定义为一个类,而每个状态类有自己对应的方法,因此当需要根据状态执行逻辑代码时不需要写大量的if-else判断是哪个状态然后执行对应的逻辑

    2024年02月02日
    浏览(49)
  • 设计模式行为型——状态模式

      目录 状态模式的定义 状态模式的实现 状态模式角色 状态模式类图 状态模式举例 状态模式代码实现 状态模式的特点 优点 缺点 使用场景 注意事项 实际应用        在软件开发过程中,应用程序中的部分对象可能会根据不同的情况做出不同的行为,把这种对象称为有状态

    2024年02月14日
    浏览(39)
  • 设计模式行为型-状态模式

    状态模式是一种行为型设计模式,用于处理对象在不同状态下的行为变化。它将对象的行为封装在不同状态类中,通过状态的切换实现不同行为的触发。 本文将介绍状态模式的基本概念、应用场景以及优势与适用性。 实现具体状态类 具体工作类: 上下文类包含状态对象的引

    2024年02月10日
    浏览(39)
  • 设计模式之状态模式(下)

    3)共享状态 1.概述 在某些情况下,多个环境对象可能需要共享同一个状态,如果希望在系统中实现多个环境对象共享一个或多个状态对象,那么需要将这些状态对象定义为环境类的静态成员对象。 2.案例 背景 :要求两个开关对象要么都处于开的状态,要么都处于关的状态,

    2024年04月25日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包