状态模式(State)

状态模式是一种行为设计模式，允许一个对象在其内部状态改变时改变它的行为，使其看起来修改了自身所属的类。其别名为状态对象(Objects for States)。

text 复制代码

State is a behavior design pattern that allows an object to change its behavior when its internal state changes,
making it appear to have modified the class it belongs to.

在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。

当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。

在UML中可以使用状态图来描述对象状态的变化。

结构设计

Context，上下文类，保存了对于一个Concrete State对象(具体状态对象)的引用，并会将所有与该状态相关的工作委派给它。上下文通过状态接口与状态对象交互。

State，状态基类，接口会声明特定于状态的方法。

Concrete State，具体状态类，会自行实现特定于状态的方法。当多个状态中包含相似代码，可以提供一个封装有部分通用行为的中间抽象类。

状态对象可存储对于上下文对象的反向引用。状态对象可以通过该引用从上下文处获取所需信息，并且能触发状态转移。但这可能会带来对象的循环引用，在实际使用时，要通过对象传参的方式使用。

状态模式类图表示如下：

状态模式可能看上去与策略模式相似，但有一个关键性的不同------在状态模式中，特定状态知道其他所有状态的存在，且能触发从一个状态到另一个状态的转换，而策略则几乎完全不知道其他策略的存在。

伪代码实现

接下来将使用代码介绍下状态模式的实现。

java 复制代码

// 1、State，状态接口，声明特定于状态的方法
public interface IState {
    void handle(StateContext context);

    void doSomething();
}

// 2、具体状态类，会自行实现特定于状态的方法，这里特定状态知道其他所有状态的存在，且能触发从一个状态到另一个状态的转换
public class ConcreteStateA implements IState {
    private static ConcreteStateA state;
    // 这里的单例实现暂不考虑并发场景
    public static IState getInstance() {
        if (state == null) {
            state = new ConcreteStateA();
        }
        return state;
    }

    @Override
    public void handle(StateContext context) {
        doSomething();
        context.setCurrentState(ConcreteStateB.getInstance());
    }

    @Override
    public void doSomething() {
        System.out.println("do some thing in the concrete A instance");
    }
}
public class ConcreteStateB implements IState {
    private static ConcreteStateB state;
    // 这里的单例实现暂不考虑并发场景
    public static IState getInstance() {
        if (state == null) {
            state = new ConcreteStateB();
        }
        return state;
    }

    @Override
    public void handle(StateContext context) {
        doSomething();
        context.setCurrentState(ConcreteStateA.getInstance());
    }

    @Override
    public void doSomething() {
        System.out.println("do some thing in the concrete B instance");
    }
}

// 3、状态上下文类，保存了对于一个Concrete State对象(具体状态对象)的引用，并会将所有与该状态相关的工作委派给它。  
// 上下文通过状态接口与状态对象交互。  
public class StateContext {
    private IState currentState;

    public StateContext(IState defaultState) {
        this.currentState = defaultState;
    }

    public IState getCurrentState() {
        return this.currentState;
    }

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

    public void request() {
        currentState.handle(this);
    }
}

// 4、客户端
public class StateClient {
    public void test() {
        StateContext stateContext = new StateContext(new ConcreteStateA());
        stateContext.request();
        stateContext.request();
        stateContext.request();
    }
}

适用场景

在以下情况下可以考虑使用状态模式：

(1) 对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为，同时状态的数量非常多且与状态相关的代码会频繁变更的话，可以考虑使用状态模式。

(2) 代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，

使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态。

(3) 当相似状态和基于条件的状态机转换中存在许多重复代码时，可考虑使用状态模式。状态模式能够生成状态类层次结构，通过将公用代码抽取到抽象基类中来减少重复。

优缺点

状态模式有以下优点：

(1) 封装了转换规则。调用方无需关心状态转换的实现。

(2) 符合开闭原则。无需修改已有状态类和上下文就能引入新状态。

(3) 符合单一职责原则。将与特定状态相关的代码放在单独的类中。

(4) 消除了可能存在的条件语句。通过消除臃肿的状态机条件语句简化上下文代码。

(5) 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

但是该模式也存在以下缺点：

(1) 如果状态机只有很少的几个状态，或者很少发生改变，那么应用该模式可能会显得小题大作。

(2) 增加系统类和对象的个数。

(3) 实现较为复杂，如果使用不当将导致程序结构和代码的混乱。

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

参考

《设计模式可复用面向对象软件的基础》 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 著, 李英军, 马晓星等译
https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/state.html 状态模式
https://refactoringguru.cn/design-patterns/state 状态模式
https://www.runoob.com/design-pattern/state-pattern.html 状态模式
https://www.cnblogs.com/adamjwh/p/10926952.html 简说设计模式------状态模式