状态模式（State Pattern）：让对象行为随状态变化的设计模式-优快云博客

本文链接：https://blog.youkuaiyun.com/sjdgehi/article/details/145875250

状态模式（State Pattern）：让对象行为随状态变化的设计模式

在实际的软件开发中，我们经常会遇到这样一种情况：一个对象在不同的状态下，应该表现出不同的行为。比如，一个订单在不同的阶段（待支付、已支付、已发货、已完成）有不同的行为或处理方式。如果我们用传统的条件语句（如if-else或switch）来处理这些状态变化，会使得代码变得臃肿和难以维护。**状态模式（State Pattern）**是一种专门解决这种问题的设计模式。

本文将深入探讨状态模式的实现原理、优缺点、应用场景，并通过大量的代码示例，帮助你更好地理解这一模式。

1. 什么是状态模式？

**状态模式（State Pattern）**是一种行为型设计模式，它允许对象在其内部状态变化时改变其行为。对象的状态和行为是高度相关的，当对象的状态发生变化时，它的行为也会相应地发生变化。

1.1 状态模式的核心思想

状态模式的核心思想是将对象的每一种可能状态封装成一个独立的类，并通过这些类来控制对象的行为。每个具体状态类都代表着一种状态的行为，它们通过统一的接口与上下文对象进行交互。

状态模式的优点是使得状态的切换和状态的行为分离，避免了大量的if-else或switch语句，使得代码更加灵活、清晰和易于扩展。

1.2 状态模式的主要角色

Context（上下文）：维护一个State子类实例，并通过State对象来协调状态切换和行为。
State（抽象状态类）：定义了一个统一的接口，各个具体状态类需要实现该接口。
ConcreteState（具体状态类）：实现具体的状态行为，每个具体状态类封装了某一特定状态下的行为。

1.3 状态模式的UML类图

    +------------------+     +------------------+
    |     Context      |<>-->|      State       |
    +------------------+     +------------------+
    | -state: State    |     | +handle()        |
    +------------------+     +------------------+
            ^
            |
    +---------------------+    +----------------------+
    |  ConcreteStateA     |    |   ConcreteStateB     |
    +---------------------+    +----------------------+
    | +handle()           |    | +handle()            |
    +---------------------+    +----------------------+

2. 状态模式的实现

接下来，我们通过一个实际的例子来展示如何使用状态模式。假设我们正在实现一个订单处理系统，订单的状态可以是“待支付”、“已支付”、“已发货”和“已完成”。每个状态下的订单都应该表现出不同的行为。

2.1 定义抽象状态类（State）

首先，我们定义一个OrderState接口，它为所有的具体状态类提供统一的接口。

// 抽象状态类：OrderState
public interface OrderState {
    void handleOrder(OrderContext context);
}

2.2 定义具体状态类（ConcreteState）

接下来，我们实现几个具体的状态类，每个状态类都会具体实现handleOrder方法，执行状态对应的行为。

2.2.1 待支付状态

// 具体状态类：PendingPaymentState
public class PendingPaymentState implements OrderState {
    @Override
    public void handleOrder(OrderContext context) {
        System.out.println("订单已创建，等待支付...");
        context.setState(new PaidState());  // 状态切换到已支付
    }
}

2.2.2 已支付状态

// 具体状态类：PaidState
public class PaidState implements OrderState {
    @Override
    public void handleOrder(OrderContext context) {
        System.out.println("支付完成，等待发货...");
        context.setState(new ShippedState());  // 状态切换到已发货
    }
}

2.2.3 已发货状态

// 具体状态类：ShippedState
public class ShippedState implements OrderState {
    @Override
    public void handleOrder(OrderContext context) {
        System.out.println("订单已发货，等待完成...");
        context.setState(new CompletedState());  // 状态切换到已完成
    }
}

2.2.4 已完成状态

// 具体状态类：CompletedState
public class CompletedState implements OrderState {
    @Override
    public void handleOrder(OrderContext context) {
        System.out.println("订单已完成，无法更改...");
        // 订单已完成，不做任何状态变更
    }
}

2.3 定义上下文类（Context）

OrderContext类充当上下文对象，它维护了当前状态，并通过状态对象来处理订单。上下文类允许状态之间的切换。

// 上下文类：OrderContext
public class OrderContext {
    private OrderState state;

    public OrderContext() {
        state = new PendingPaymentState();  // 初始状态为待支付
    }

    public void setState(OrderState state) {
        this.state = state;
    }

    public void handleOrder() {
        state.handleOrder(this);
    }
}

2.4 客户端代码

最后，我们在客户端代码中演示如何使用状态模式来处理订单。

// 客户端代码
public class Client {
    public static void main(String[] args) {
        OrderContext order = new OrderContext();

        // 测试状态转移：待支付 -> 已支付 -> 已发货 -> 已完成
        order.handleOrder();  // 订单创建，等待支付
        order.handleOrder();  // 支付完成，等待发货
        order.handleOrder();  // 订单已发货，等待完成
        order.handleOrder();  // 订单已完成，无法更改
    }
}

2.5 运行结果

订单已创建，等待支付...
支付完成，等待发货...
订单已发货，等待完成...
订单已完成，无法更改...

3. 状态模式的优缺点

3.1 优点

状态和行为分离：每个状态都封装了对应的行为，代码清晰且易于维护。每个状态类只关心自己的行为，不关心其他状态的行为。
扩展性强：增加新的状态非常简单，只需增加新的状态类，并在上下文类中适当切换即可。
避免庞大的条件语句：避免了在对象内部写大量的if-else或switch语句，使得代码更加简洁和易于理解。

3.2 缺点

状态类过多：如果对象的状态非常复杂，可能会导致状态类数量激增，增加系统的复杂性。
上下文类变复杂：虽然每个状态类的行为很简单，但上下文类需要维护所有状态的切换逻辑，如果状态过多，上下文类也会变得臃肿。

4. 状态模式与其他模式的对比

特性	状态模式	策略模式	状态模式与策略模式的对比
目的	根据对象的状态改变其行为	根据不同策略改变对象行为	状态模式依赖状态切换，策略模式依赖策略切换
核心思想	将每个状态封装成一个类，状态变化时切换行为	将算法封装成策略类，允许动态选择算法	状态模式和策略模式都涉及行为的变化，状态模式关注状态之间的切换，而策略模式关注算法之间的切换
适用场景	状态复杂变化且行为有很大差异的场景	算法需要动态切换，且算法不依赖于状态	状态模式侧重于对象状态变化，策略模式侧重于不同算法的选择