架构师小白

Posted on Jun 26

状态模式深度指南：构建可动态切换行为的艺术

#java #programming #tutorial #beginners

状态模式深度指南：构建可动态切换行为的艺术

概述

状态模式（State Pattern）是一种行为型设计模式，它允许对象在内部状态改变时改变其行为。看起来对象似乎修改了其类。这种模式是解决复杂状态转换逻辑的利器，特别适合用于工作流引擎、游戏开发、订单处理系统等场景。

核心概念

状态模式的核心思想是：将每个状态封装为独立的类，对象的行为取决于其当前状态，而状态之间的转换由状态类自己管理。

关键角色

Context（上下文）：维护当前状态的实例，负责将请求委托给状态对象处理
State（抽象状态）：定义所有具体状态的共同接口
ConcreteState（具体状态）：实现各个具体状态的行为，并负责状态转换

为什么需要状态模式？

传统方式的困境

想象一个订单系统，订单有多种状态：待支付、待发货、已发货、已完成、已取消。每个状态下可以执行不同的操作。

// 传统的if-else方式
class Order {
    public void process() {
        if (status.equals("待支付")) {
            // 处理支付逻辑
        } else if (status.equals("待发货")) {
            // 处理发货逻辑
        } else if (status.equals("已发货")) {
            // 处理签收逻辑
        }
        // ... 越来越多的条件判断
    }
}

这种方式的问题：

代码膨胀：每个方法都包含大量if-else
难以维护：新增状态需要修改多个方法
违反开闭原则：无法在不修改现有代码的情况下添加新状态
状态逻辑分散：状态转换规则散落在各处

状态模式的解决方案

状态模式通过将每个状态封装为独立类，让每个状态负责自己的行为和转换逻辑，从而解决上述问题。

实战案例：订单状态管理系统

1. 定义抽象状态接口

public interface OrderState {
    void pay(OrderContext context);
    void ship(OrderContext context);
    void deliver(OrderContext context);
    void cancel(OrderContext context);
    String getStatusName();
}

2. 创建具体状态类

// 待支付状态
public class PendingPaymentState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        System.out.println("订单支付成功！");
        context.setState(new PendingShipmentState());
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单未支付，无法发货");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单未发货，无法签收");
    }

    @Override
    public void cancel(OrderContext context) {
        System.out.println("订单已取消");
        context.setState(new CancelledState());
    }

    @Override
    public String getStatusName() {
        return "待支付";
    }
}

// 待发货状态
public class PendingShipmentState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已支付");
    }

    @Override
    public void ship(OrderContext context) {
        System.out.println("商品已发货！");
        context.setState(new ShippedState());
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单未发货");
    }

    @Override
    public void cancel(OrderContext context) {
        System.out.println("取消发货，订单退款中");
        context.setState(new CancelledState());
    }

    @Override
    public String getStatusName() {
        return "待发货";
    }
}

// 已发货状态
public class ShippedState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已支付");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("商品已发货");
    }

    @Override
    public void deliver(OrderContext context) {
        System.out.println("订单已完成！");
        context.setState(new CompletedState());
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("商品已发出，无法取消");
    }

    @Override
    public String getStatusName() {
        return "已发货";
    }
}

// 已完成状态
public class CompletedState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("已完成订单无法取消");
    }

    @Override
    public String getStatusName() {
        return "已完成";
    }
}

// 已取消状态
public class CancelledState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public String getStatusName() {
        return "已取消";
    }
}

3. 创建上下文类

public class OrderContext {
    private OrderState state;
    private String orderId;

    public OrderContext(String orderId) {
        this.orderId = orderId;
        this.state = new PendingPaymentState(); // 初始状态
    }

    public void setState(OrderState state) {
        this.state = state;
        System.out.println("订单状态变更为: " + state.getStatusName());
    }

    public OrderState getState() {
        return state;
    }

    // 委托给当前状态处理
    public void pay() {
        state.pay(this);
    }

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

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

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

4. 客户端使用

public class Client {
    public static void main(String[] args) {
        OrderContext order = new OrderContext("ORDER-001");

        order.pay();        // 支付 -> 待发货
        order.ship();       // 发货 -> 已发货
        order.deliver();    // 签收 -> 已完成
    }
}

输出：

订单支付成功！
订单状态变更为: 待发货
商品已发货！
订单状态变更为: 已发货
订单已完成！
订单状态变更为: 已完成

状态模式的优缺点

优点

单一职责：每个状态类只负责自己的行为和状态转换
开闭原则：新增状态只需添加新的状态类，不影响现有代码
消除条件判断：用多态替代大量的if-else
状态转换明确：状态转换逻辑集中在状态类中，便于管理和调试

缺点

类数量增加：每个状态都需要一个独立类
学习曲线：对于新手来说，代码结构需要理解时间
过度设计：对于简单场景可能过于复杂

状态模式 vs 策略模式

这两个模式结构非常相似，但意图不同：

特性	状态模式	策略模式
意图	对象行为随状态自动改变	算法/策略可替换
参与者	上下文知道状态，状态知道转换	上下文选择策略，策略相互独立
改变时机	状态类内部决定转换	客户端决定使用哪个策略
耦合度	状态类之间有依赖	策略类之间通常独立

简单来说：策略模式是"我不变，但你可以换策略"，状态模式是"我变了，所以行为也变"。

实际应用场景

工作流引擎：审批流程、状态流转
游戏开发：角色状态（站立、跑步、跳跃、攻击）
订单系统：订单生命周期管理
ATM机：不同状态下的操作行为
网络协议：TCP连接状态管理

状态机与状态模式

对于更复杂的状态转换，建议引入状态机框架：

// 使用Spring Statemachine
@Configuration
@EnableStateMachine
public class OrderStateMachineConfig extends StateMachineConfigurerAdapter<OrderStates, OrderEvents> {

    @Override
    public void configure(StateMachineStateConfigurer<OrderStates, OrderEvents> states) throws Exception {
        states
            .withStates()
            .initial(OrderStates.PENDING_PAYMENT)
            .states(EnumSet.allOf(OrderStates.class))
            .end(OrderStates.COMPLETED)
            .end(OrderStates.CANCELLED);
    }

    @Override
    public void configure(StateMachineTransitionConfigurer<OrderStates, OrderEvents> transitions) throws Exception {
        transitions
            .withExternal()
                .source(OrderStates.PENDING_PAYMENT)
                .target(OrderStates.PENDING_SHIPMENT)
                .event(OrderEvents.PAY)
            .and()
            .withExternal()
                .source(OrderStates.PENDING_SHIPMENT)
                .target(OrderStates.SHIPPED)
                .event(OrderEvents.SHIP);
    }
}

总结

状态模式是处理复杂状态逻辑的利器，它将状态转换封装到独立的状态类中，使得代码更加清晰、易于维护。当你的系统有以下特征时，考虑使用状态模式：

对象行为依赖其内部状态
状态转换逻辑复杂，包含大量条件判断
需要在不修改现有代码的情况下添加新状态
状态转换需要被明确跟踪和管理

掌握状态模式，让你的代码更具可维护性和扩展性！

参考资源：

《设计模式：可复用面向对象软件的基础》
Spring Statemachine 官方文档

DEV Community

状态模式深度指南：构建可动态切换行为的艺术

状态模式深度指南：构建可动态切换行为的艺术

概述

核心概念

关键角色

为什么需要状态模式？

传统方式的困境

状态模式的解决方案

实战案例：订单状态管理系统

1. 定义抽象状态接口

2. 创建具体状态类

3. 创建上下文类

4. 客户端使用

状态模式的优缺点

优点

缺点

状态模式 vs 策略模式

实际应用场景

状态机与状态模式

总结

Top comments (0)