Java 设计模式之状态模式

设计模式

发布日期: 2018-10-14

文章字数: 2.4k

阅读时长: 8 分

模式动机

对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。

在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。

模式定义

状态模式(State Pattern)允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)。

状态模式是一种对象行为型模式。

模式结构

角色组成

状态模式包含如下角色：

Context(环境角色)环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类 State 的实例，这个实例定义当前状态，在具体实现时，它是一个 State 子类的对象。
State(抽象状态角色)它用于定义一个接口以封装与环境类的一个特定状态相关的行为，在抽象状态类中声明了各种不同状态对应的方法，而在其子类中实现类这些方法，由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。
ConcreteState(具体状态角色)它是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。

在状态模式中，我们将对象在不同状态下的行为封装到不同的状态类中，为了让系统具有更好的灵活性和可扩展性，同时对各状态下的共有行为进行封装，我们需要对状态进行抽象。

结构图

状态模式结构图

时序图

状态模式时序图

模式实现

首先，是抽象状态角色。State 抽象类充当抽象状态角色，完整代码如下所示：

/**
 * 抽象状态角色
 */
abstract class State {
    /**
     * 声明抽象业务方法，不同的具体状态类可以不同的实现
     */
    public abstract void handle();
}

接下来，是具体状态角色。ConcreteStateA 和 ConcreteStateB 类充当具体状态角色，完整代码如下所示：

/**
 * 具体状态角色类A
 */
public class ConcreteStateA extends State {

    /**
     * 具体状态角色类A中的方法
     */
    @Override
    public void handle() {
        System.out.println("执行了具体状态角色类A中的方法...");
    }

}

/**
 * 具体状态角色类B
 */
public class ConcreteStateB extends State {

    /**
     * 具体状态角色类B中的方法
     */
    @Override
    public void handle() {
        System.out.println("执行了具体状态角色类B中的方法...");
    }

}

在抽象状态类的子类即具体状态类中实现了在抽象状态类中声明的业务方法，不同的具体状态类可以提供完全不同的方法实现，在实际使用时，在一个状态类中可能包含多个业务方法，如果在具体状态类中某些业务方法的实现完全相同，可以将这些方法移至抽象状态类，实现代码的复用。

然后，是环境类。Context 类充当环境类，完整代码如下所示：

/**
 * 环境角色类
 */
public class Context {

    /** 当前状态 */
    private State state;

    /**
     * 设置状态对象
     */
    public void setState(State state) {
        this.state = state;
    }

    /**
     * 方法
     */
    public void request() {
        // 其他代码
        this.state.handle();
        // 其他代码
    }

}

环境类实际上是真正拥有状态的对象，我们只是将环境类中与状态有关的代码提取出来封装到专门的状态类中。在状态模式结构图中，环境类 Context 与抽象状态类 State 之间存在单向关联关系，在 Context 中定义了一个 State 对象。在实际使用时，它们之间可能存在更为复杂的关系，State 与 Context 之间可能也存在依赖或者关联关系。

最后，是客户端场景类，完整代码如下所示：

public class StateClient {

    public static void main(String[] args) {
        ConcreteStateA stateA = new ConcreteStateA();
        Context context = new Context();
        context.setState(stateA);
        context.request();
    }

}

模式分析

状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中，通过设置不同的状态对象可以让环境对象拥有不同的行为，而状态转换的细节对于客户端而言是透明的，方便了客户端的使用。在实际开发中，状态模式具有较高的使用频率，在工作流和游戏开发中状态模式都得到了广泛的应用，例如公文状态的转换、游戏中角色的升级等。

优点

状态模式的主要优点如下：

封装了状态的转换规则，在状态模式中可以将状态的转换代码封装在环境类或者具体状态类中，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中。
将所有与某个状态有关的行为放到一个类中，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。
允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块，状态模式可以让我们避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。
可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

缺点

状态模式的主要缺点如下：

状态模式的使用必然会增加系统中类和对象的个数，导致系统运行开销增大。
状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度。
状态模式对“开闭原则”的支持并不太好，增加新的状态类需要修改那些负责状态转换的源代码，否则无法转换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。

适用环境

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

对象的行为依赖于它的状态（如某些属性值），状态的改变将导致行为的变化。
在代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，并且导致客户类与类库之间的耦合增强。

总结

状态模式允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象，状态模式是一种对象行为型模式。
状态模式包含三个角色：环境类又称为上下文类，它是拥有状态的对象，在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象，可以定义初始状态；抽象状态类用于定义一个接口以封装与环境类的一个特定状态相关的行为；具体状态类是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。
状态模式描述了对象状态的变化以及对象如何在每一种状态下表现出不同的行为。
状态模式的主要优点在于封装了转换规则，并枚举可能的状态，它将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为，还可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数；其缺点在于使用状态模式会增加系统类和对象的个数，且状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱，对于可以切换状态的状态模式不满足“开闭原则”的要求。
状态模式适用情况包括：对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为；代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。