[特殊字符]状态模式：代码界的“交通指挥员”，让对象行为随状态智能切换！-优快云博客

🚦状态模式：代码界的“交通指挥员”，让对象行为随状态智能切换！

一、状态模式初体验

在这里插入图片描述

✨你是否遇到过订单状态的复杂变化？从“待付款”到“已发货”，不同状态下的操作逻辑大相径庭。又或者在开发游戏时，角色从“待机”到“攻击”状态的转变，行为也截然不同。在这些场景中，状态模式就派上用场啦！

就像代码界的“交通指挥员”，能让对象根据当前状态自动切换行为，避免臃肿的判断！

二、核心概念全解析

2.1 模式定义与原理

状态模式，听名字就知道和“状态”紧密相关。它的定义是：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。简单来说，就是把对象的每个状态都独立成一个类，当对象的状态发生变化时，它的行为也会自动更新。

其原理基于一个三层结构：环境类（Context）、状态接口（State）和具体状态类（ConcreteState）。环境类持有一个当前状态的引用，负责管理状态的切换；状态接口定义了状态相关的行为方法；具体状态类则实现了这些行为，每个具体状态类对应一种特定的状态。

举个生活中的例子，就像自动贩卖机。在投币前，它处于“未投币”状态，此时选择商品的操作是无效的，按任何按钮都不会出货；当投币后，它进入“已投币”状态，这时就可以选择商品并出货了。这就是状态模式的直观体现，不同状态下贩卖机的行为截然不同。

2.2 四大核心角色

在状态模式的舞台上，有四个核心角色，它们各司其职，共同演绎出状态模式的精彩：

环境类（Context）：就像是舞台的总导演，持有当前状态的引用，负责管理状态的切换。它对外提供统一的接口，让外部调用者无需关心内部状态的变化细节。在订单系统中，环境类就是订单对象，它持有订单当前的状态，比如“待付款”“已发货”等。

抽象状态（State）：如同一个抽象的剧本大纲，定义了状态相关行为的接口。它为具体状态类提供了一个统一的规范，让所有具体状态类都遵循这个规范来实现自己的行为。在订单系统里，抽象状态就是订单状态的抽象类，它定义了如支付、发货、收货等行为的接口。

具体状态（ConcreteState）：是一个个具体的演员，根据剧本大纲（抽象状态）来实现特定状态下的具体行为。每个具体状态类都对应一种实际的状态，实现了在该状态下的各种操作。比如订单系统中的“待付款状态”类，实现了在待付款状态下可以进行支付操作；“已发货状态”类，实现了在已发货状态下可以进行确认收货操作。

客户端（Client）：是台下的观众，它触发状态的转换。客户端通过调用环境类的方法，间接地触发状态的改变。在订单系统中，用户就是客户端，当用户支付订单时，就触发了订单从“待付款”状态到“已支付”状态的转换。

三、Java 代码实战：订单状态管理

3.1 基础案例

下面通过一个订单状态管理的示例，来深入理解状态模式在 Java 中的实现。假设一个订单有“待付款”“已付款”“已发货”“已完成”这几种状态，不同状态下订单的行为不同。

// 订单上下文类，环境类
class Order {
    // 持有当前订单状态的引用
    private OrderState state;

    // 构造函数，初始化订单状态为待付款状态
    public Order() {
        this.state = new PendingState();
    }

    // 设置订单状态的方法
    public void setState(OrderState state) {
        this.state = state;
    }

    // 处理订单的方法，委托给当前状态对象处理
    public void handle() {
        state.handle(this);
    }
}

// 订单状态接口，抽象状态
interface OrderState {
    // 处理订单状态的方法，接收订单上下文对象
    void handle(Order order);
}

// 待付款状态类，具体状态
class PendingState implements OrderState {
    @Override
    public void handle(Order order) {
        System.out.println("订单处于待付款状态，正在处理支付...");
        // 支付完成后，将订单状态转换为已付款状态
        order.setState(new PaidState());
    }
}

// 已付款状态类，具体状态
class PaidState implements OrderState {
    @Override
    public void handle(Order order) {
        System.out.println("订单已支付，正在处理发货...");
        // 发货后，将订单状态转换为已发货状态
        order.setState(new ShippedState());
    }
}

// 已发货状态类，具体状态
class ShippedState implements OrderState {
    @Override
    public void handle(Order order) {
        System.out.println("订单已发货，等待客户确认...");
        // 客户确认收货后，将订单状态转换为已完成状态
        order.setState(new CompletedState());
    }
}

// 已完成状态类，具体状态
class CompletedState implements OrderState {
    @Override
    public void handle(Order order) {
        System.out.println("订单已完成，感谢您的购买！");
        // 已完成状态下，不需要再进行状态转换
    }
}

3.2 执行结果

通过以下测试代码，来观察订单状态的变化和行为的执行：

public class StatePatternExample {
    public static void main(String[] args) {
        Order order = new Order();
        // 处理待付款状态
        order.handle();
        // 处理已付款状态
        order.handle();
        // 处理已发货状态
        order.handle();
        // 处理已完成状态
        order.handle();
    }
}

执行上述代码，控制台输出结果如下：

订单处于待付款状态，正在处理支付...
订单已支付，正在处理发货...
订单已发货，等待客户确认...
订单已完成，感谢您的购买！

从结果可以清晰地看到，订单在不同状态下执行了相应的操作，并且状态也按照预期进行了转换。

四、应用场景大揭秘

状态模式在实际开发中有着广泛的应用场景，以下是一些常见的例子：

订单状态管理：在电商平台中，订单的状态从“待付款”“已付款”“已发货”到“已完成”，每个状态下的操作和逻辑都不同。通过状态模式，将不同状态下的操作封装在各自的状态类中，使得代码结构清晰，易于维护和扩展。当订单处于“待付款”状态时，用户可以进行支付操作，支付成功后订单状态切换到“已付款”；在“已付款”状态下，商家可以进行发货操作，发货后订单状态变为“已发货”。这样的状态管理方式，让订单流程的代码逻辑一目了然，避免了大量复杂的条件判断语句。

设备状态控制：智能家电如智能空调、智能电视等，它们有着不同的状态，如“关机”“开机”“运行”“待机”等。以智能空调为例，在“关机”状态下，用户按下开机按钮，空调进入“开机”状态并进行初始化操作；在“运行”状态下，用户可以调节温度、风速等参数，这些操作在不同状态下的行为和限制是不同的。使用状态模式，能够清晰地定义每个状态下设备的行为，方便对设备的控制和管理。当空调处于“待机”状态时，它的功耗较低，仅响应一些基本的唤醒操作；而在“运行”状态下，它会根据用户设定的参数进行制冷或制热等操作。

工作流引擎：在审批流程中，任务从“待审批”“审批中”“审批通过”到“审批不通过”，每个阶段的处理逻辑和参与者都不同。比如在一个请假审批流程中，员工提交请假申请后，任务处于“待审批”状态，此时直属领导可以进行审批操作；领导审批时，任务进入“审批中”状态，领导审批通过后，任务状态变为“审批通过”，流程结束；如果领导审批不通过，任务则进入“审批不通过”状态，并通知员工。状态模式可以很好地管理这种审批流程的状态变化，使流程的控制和维护更加方便。

游戏角色状态：在 RPG 游戏中，角色可能有“战斗”“休息”“移动”等状态。当角色处于“战斗”状态时，会执行攻击、防御等动作，并且受到战斗规则的约束；在“休息”状态下，角色可以恢复生命值和魔法值。以经典游戏《魔兽世界》为例，角色在战斗状态下，技能的释放、生命值的变化等都有特定的逻辑；而在休息状态下，角色的回血回蓝速度会加快。状态模式让游戏角色的行为更加丰富和合理，提升了游戏的趣味性和可玩性。

五、优缺点大 PK

状态模式就像一把双刃剑，在带来诸多好处的同时，也存在一些不足之处。

5.1 优点

解耦状态与行为：状态模式将对象的行为与状态的变化进行解耦，使得状态的变化可以独立于具体行为的实现。每个状态类都专注于实现自身状态下的行为，而环境类只负责管理状态的切换，这样代码结构更加清晰，维护起来也更加容易。在订单状态管理的例子中，“待付款”“已付款”等状态类各自实现了对应状态下的操作逻辑，与订单类本身的其他业务逻辑分离，降低了代码的耦合度。

扩展性强：符合开闭原则，当需要新增状态时，只需要添加新的状态类，而无需修改已有的代码。这使得系统具有良好的扩展性，能够轻松应对业务需求的变化。比如在电商系统中，如果要新增“退款中”的订单状态，只需要创建一个“RefundingState”类实现订单状态接口，然后在需要的地方进行状态切换即可，不会影响到其他已有的状态类和业务逻辑。

清晰的状态转换：将状态转换逻辑集中在环境类或状态类中，使得状态之间的转换更加明确和可维护。避免了在业务代码中出现大量复杂的条件判断语句，提高了代码的可读性。以智能家电的状态控制为例，通过状态模式，不同状态之间的转换逻辑一目了然，从“关机”到“开机”，从“运行”到“待机”等操作都有清晰的定义和实现。

可维护性提高：将与某个状态相关的行为都封装在一个类中，方便对这些行为进行修改和维护。当某个状态下的行为需要调整时，只需要修改对应的状态类即可，不会影响到其他状态和整个系统的稳定性。在游戏开发中，如果要调整角色在“战斗”状态下的攻击行为，只需要在“FightingState”类中进行修改，而不会对角色的其他状态和行为产生影响。

5.2 缺点

类数量增加：每个状态都需要单独定义一个类，当状态数量较多时，会导致系统中类的数量大幅增加，增加了系统的复杂性和维护成本。如果一个系统中有几十甚至上百种状态，那么相应的状态类也会非常多，这会使得代码的管理和理解变得困难。在复杂的工作流系统中，可能存在多种任务状态，如“待分配”“处理中”“审核中”“已完成”“已驳回”等，状态类的增多会使代码结构变得臃肿。

状态依赖问题：状态之间的转换逻辑可能会集中在环境类中，导致环境类对状态类的依赖较强。如果状态之间的转换规则发生变化，可能需要修改环境类的代码，这在一定程度上违背了开闭原则。而且状态类之间可能也存在一些依赖关系，使得代码的灵活性和可维护性受到影响。在订单状态管理中，如果订单状态的转换规则发生改变，比如“已付款”状态在某些特殊情况下可以直接转换为“已完成”状态，可能就需要修改订单类（环境类）中状态切换的逻辑。

学习成本增加：对于初学者来说，理解和掌握状态模式需要一定的时间和精力。它涉及到多个角色和复杂的状态转换逻辑，需要对设计模式的概念和原理有深入的理解才能正确应用。相比简单的条件判断语句，状态模式的学习曲线较陡。在学习状态模式时，需要理解环境类、抽象状态类、具体状态类之间的关系和协作方式，以及状态转换的实现机制。

六、避坑指南

在使用状态模式时，也有一些容易踩坑的地方需要注意：

状态隔离：确保每个状态类的职责单一，避免不同状态的逻辑混淆。每个状态类应该只关注自己状态下的行为实现，不要在一个状态类中处理过多其他状态的逻辑。如果在“待付款状态”类中，除了处理支付逻辑，还处理了发货相关的逻辑，就违背了状态隔离的原则，会导致代码混乱，难以维护。

状态初始化：明确对象的初始状态，以及状态之间合法的转换路径。在订单状态管理中，订单初始状态通常是“待付款”，如果初始状态设置错误，可能会导致后续流程出现问题。同时，要确保状态转换的逻辑正确，不能出现不合理的状态转换，比如“已完成”状态再转换回“待付款”状态，除非有特殊业务需求。

线程安全：在多线程环境下使用状态模式，要注意状态的同步和线程安全问题。如果多个线程同时访问和修改对象的状态，可能会导致状态不一致或数据错误。可以使用synchronized关键字或者Lock接口来实现线程同步。在订单支付过程中，如果多个线程同时处理支付操作，可能会导致订单状态的混乱，需要对支付操作进行同步控制。

结合工厂模式：当状态对象的创建比较复杂时，可以结合工厂模式来动态创建状态对象。这样可以将状态对象的创建逻辑封装在工厂类中，提高代码的可维护性和可扩展性。在订单状态管理中，如果“待付款状态”对象的创建需要进行一些复杂的初始化操作，可以使用工厂模式来创建该状态对象。

七、模式对比

在设计模式的大家庭中，状态模式与策略模式、责任链模式有一些相似之处，但也有着明显的区别。通过对比，能更好地理解状态模式的独特之处：

模式	核心差异	适用场景
策略	动态选择算法	支付方式切换
状态	状态驱动行为	订单状态流转
责任链	请求链式传递	审批流程

策略模式侧重于动态选择算法，比如在支付系统中，用户可以选择支付宝、微信支付等不同的支付策略。而状态模式重点在于状态驱动行为，像订单状态的流转，不同状态下订单的操作不同。责任链模式则是将请求沿着链传递，直到有一个对象处理它，常用于审批流程，如请假审批，从员工提交申请，依次经过直属领导、部门经理等审批。