设计模式之——状态模式

对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为 ,属于行为型模式，允许一个对象在其内部状态改变时改变它的行为

状态模式是策略模式的孪生兄弟，它们的UML图是一样的，但实际上解决的是不同情况的两种场景问题，工作中用的不多，基本是策略模式比较多

应用场景

• 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为
• 代码中包含大量与对象状态有关的条件语句 ，比如一个操作中含有庞大的多分支的条件if else语句，且这些分支依赖于该对象的状态
• 电商订单状态：未支付、已支付、派送中，收货完成等状态，各个状态下处理不同的事情

角色

• Context 上下文：定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理
• State 抽象状态类： 定义一个接口以封装与Context的一个特定状态相关的行为
• ConcreteState具体状态类： 实现抽象状态定义的接口

代码实现

以电商订单状态流转为例，每步都有不同的操作内容: 新建订单/已支付/已发货/确认收货

public interface State {
​
    void handle();
}

接口实现

public class NewOrderState implements State{
​
    @Override
    public void handle() {
        System.out.println("新订单，未支付");
        System.out.println("调用商户客服服务，有新订单\n");
    }
}

public class PayOrderState implements State{
​
    @Override
    public void handle() {
        System.out.println("新订单已经支付");
        System.out.println("调用商户客服服务，订单已经支付");
        System.out.println("调用物流服务，未发货\n");
    }
}

public class SendOrderState implements State{
​
    @Override
    public void handle() {
        System.out.println("订单已经发货");
        System.out.println("调用短信服务，告诉用户已经发货");
        System.out.println("更新物流信息\n");
    }
}

public class OrderContext {
​
    private State state;
​
    public OrderContext(){}
​
    public void setState(State state) {
        this.state = state;
        System.out.println("订单状态变更！！");
        this.state.handle();
    }
}

测试

public static void main(String[] args) {
​
    OrderContext orderContext = new OrderContext();
​
    orderContext.setState(new NewOrderState());
​
    orderContext.setState(new PayOrderState());
​
    orderContext.setState(new SendOrderState());
​}

优点

1、结构清晰：将状态类独立为类，消除了冗余的if...else 或 switch...case 语句，使代码更加简洁，提高系统可维护性

2、将状态转换显示化：通常的对象内部都是使用数值类型来定义状态，状态的切换是通过赋值进行表现，不够直观；而使用状态类，在切换时，是以不同的类进行表示，转换目的更加明确

3、状态类职责明确且具备扩展性

缺点

1、类膨胀：如果一个事物具备很多状态，则会造成状态类太多

2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的婚礼

3、状态模式对开闭原则的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需要修改对应类的源代码