Java设计模式-状态模式

状态模式（State Pattern）是一种非常巧妙的行为型设计模式。它的核心思想可以用一句话概括：当一个对象的内部状态发生改变时，它的行为也跟着改变。

听起来有点抽象？其实它最厉害的地方在于，它让对象看起来就像是修改了它的类一样。这通常是因为我们将"状态"封装成了独立的类。

为了帮你彻底理解，我将从核心逻辑、代码结构、优缺点到实际应用为你详细拆解。

1. 核心逻辑：告别"面条代码"

在没有使用状态模式的传统编程中，我们通常会用大量的 if-else 或 switch-case 语句来判断对象的状态，并执行不同的逻辑46。

例如，一个订单对象可能有"待支付"、"已支付"、"已发货"等状态。如果用传统方式写，代码可能会长这样：

java 复制代码

if (state == "待支付") {
    // 执行支付逻辑
} else if (state == "已支付") {
    // 执行发货逻辑
} else if ... // 后面可能还有几十行

随着状态增多，这段代码会变得极其臃肿、难以维护（俗称"面条代码"）。

状态模式的解法是：

把每一个状态都封装成一个独立的类。每个类只负责自己状态下的行为。环境类（Context）不需要知道当前是什么状态，它只需要把请求"委托"给当前的状态对象去处理即可。

2. 核心角色

状态模式通常包含以下三个角色：

Context（环境类/上下文）：

它是用户直接打交道的类。

它持有一个 State 接口的引用。

它将状态相关的请求委托给当前的状态对象来处理。

State（抽象状态类）：

定义了一个接口，封装了与 Context 状态相关的行为。

ConcreteState（具体状态类）：

实现 State 接口。

每一个子类实现一个与 Context 状态相关的行为（例如 PendingPaymentState、PaidState）。

3. 代码示例（简化版）

我们继续用订单的例子来演示：

第一步：定义状态接口

java 复制代码

// 抽象状态接口
public interface OrderState {
    void pay();   // 支付
    void ship();  // 发货
}

第二步：实现具体状态

java 复制代码

// 待支付状态
public class PendingPaymentState implements OrderState {
    @Override
    public void pay() {
        System.out.println("订单支付成功");
        // 这里可以改变环境类的状态为"已支付"
    }

    @Override
    public void ship() {
        System.out.println("错误：请先支付订单");
    }
}

// 已支付状态
public class PaidState implements OrderState {
    @Override
    public void pay() {
        System.out.println("错误：订单已支付");
    }

    @Override
    public void ship() {
        System.out.println("订单发货成功");
    }
}

第三步：环境类（订单）

java 复制代码

public class Order {
    private OrderState currentState;

    // 构造函数，默认为待支付状态
    public Order() {
        this.currentState = new PendingPaymentState();
    }

    // 委托给状态对象处理
    public void pay() {
        currentState.pay();
    }

    public void ship() {
        currentState.ship();
    }

    // 提供给状态类修改自身状态的方法
    public void setState(OrderState state) {
        this.currentState = state;
    }
}

第四步：客户端调用

java 复制代码

Order order = new Order();
order.ship(); // 输出：错误：请先支付订单

order.pay();  // 输出：订单支付成功
order.ship(); // 此时状态已变，输出：订单发货成功

4. 优缺点分析

✅ 优点：

封装性好：将特定状态的行为局部化，符合"单一职责原则"。

消除条件语句：去掉了庞大的 if-else 或 switch，代码结构更清晰。

易于扩展：如果要增加新的状态，只需要新增一个具体状态类，无需修改现有代码（开闭原则）。

❌ 缺点：

类数量增多：每一个状态都要一个类，如果状态很多，系统类的数量会急剧增加。

切换逻辑复杂：状态之间的转换逻辑（从A状态怎么跳到B状态）如果处理不好，可能会导致代码混乱。有时需要在状态类内部维护对 Context 的引用，或者使用状态机来管理，增加了复杂度。

5. 适用场景

当你遇到以下情况时，应该优先考虑状态模式：

行为依赖状态：一个对象的行为取决于它的状态，并且状态在运行时经常改变。

复杂条件判断：代码中包含庞大的多分支 if-else 或 switch-case 语句，这些分支逻辑非常复杂。

状态流转明确：对象有明确的生命周期或状态流转路径（如：开始 -> 运行 -> 暂停 -> 结束）。

常见案例：

订单系统（待支付、已支付、退款中、已完成）。

游戏开发（角色的行走、攻击、防御、死亡状态）。

工作流引擎（任务的待处理、处理中、已完成）。

UI 控件（按钮的可用、禁用、按下状态）