设计模式之状态模式

文章目录

设计模式之状态模式
一、状态模式是什么？
二、状态模式详解
- 1.状态模式组成
- 2.示例demo
总结
- 优点
- 缺点

一、状态模式是什么？

状态模式是对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。状态模式一般用于行为随着状态的改变而改变的场景。例如订单的支付状态。

二、状态模式详解

1.状态模式组成

状态模式以下角色构成：

环境类（Context）角色：也称为上下文，它定义了客户端需要的接口，内部维护一个当前状态，并负责具体状态的切换。
抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为，可以有一个或多个行为。
具体状态（Concrete State）角色：实现抽象状态所对应的行为，并且在需要的情况下进行状态切换。

2.示例demo

下面用订单举例：

环境类订单：

@Data
public class Order {
    //订单的状态
    private PayStatus status;
}

抽象状态：

//订单状态接口
public interface PayStatus {

    public void doAction(Order order);
}

订单的具体支付状态：

//支付成功
public class PaySuccess implements PayStatus{

    @Override
    public void doAction(Order order) {
        /**
         * 支付成功，执行货物库存的修改等一系列操作
         */
        order.setStatus(this); //修改订单的状态
    }
}
//支付失败
public class PayFail implements PayStatus{

    @Override
    public void doAction(Order order) {
        /**
         * 支付失败，不扣库存
         */
        order.setStatus(this); //修改订单的状态
    }
}

使用：

  public static void main(String[] args) {
        //有一个订单
        Order order = new Order();
        //订单支付失败
        doPay(order,new PayFail());
        //订单支付成功
        doPay(order,new PaySuccess());

    }

    /**
     * 订单支付操作
     * @param order  订单
     * @param payStatus  支付状态
     */
    private static void doPay(Order order,PayStatus payStatus){
        payStatus.doAction(order);
        /**
         * 订单的支付操作结束，后面写入日志、数据库等操作是一样的
         */
    }

订单不同的状态要执行不同的操作，使用了状态模式是不是简单明了，而且假设我们还有其他状态的时候只需要扩展一个状态就行了，不需要去修改订单对象，而且也不需要修改订单执行的业务逻辑，把其他操作需要影响的业务功能写在新的状态中就可以了。

总结

优点

结构清晰明了，代码可读性提高；
减少了代码之间的依赖性，将不同状态需要做的业务放在状态中更加明确每个状态执行的操作；
新增状态的时候易于扩展

缺点

状态模式会增加代码类的数量；
如果状态较多且乱用状态的情况下不会使代码易读反而提高了阅读难度；
状态模式对开闭原则的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源码，否则无法切换到新增状态，而且修改某个状态类的行为也需要修改对应类的源码（对于这个缺点可能大多数人不太理解，这里的可以切换状态是可以随时切换的例如前端上组件的显示隐藏随时一直切换，而不像订单这种可能最后我们就用一个状态结束了这项业务）。

状态模式和策略模式都是减少代码中的if判断，两者的区别是状态模式是对象的内部状态，对外的表现只是对象的状态发生了变化；而策略模式需要用户自己去判断当前业务应该使用那种策略，所以其对外是暴露的。