Java 设计模式之状态模式：让对象的行为随状态优雅变化
在软件开发中，我们经常会遇到这样一类对象：它们的行为会随着自身状态的改变而发生显著变化。比如订单会经历待支付、已支付、已发货、已完成等状态，不同状态下订单能执行的操作截然不同；又如电梯有运行、停止、开门、关门等状态，每个状态下的可用操作也各有不同。状态模式（State Pattern）正是为这类场景提供了优雅的解决方案。
什么是状态模式？
状态模式是一种行为型设计模式，它允许对象在内部状态改变时改变其行为，使对象看起来好像修改了它的类。
这种模式的核心思想是：将对象的状态封装成独立的状态类，每个状态类负责定义该状态下对象的行为，从而将状态判断逻辑从主体类中移除，使代码更清晰、更易维护。
状态模式的核心角色
实现状态模式通常需要以下几个核心角色：
- 环境类（Context）：维护一个当前状态的引用，负责将状态相关的操作委托给当前状态对象
- 抽象状态类（State）：定义所有具体状态类需要实现的接口，通常包含与环境类相关的操作方法
- 具体状态类（ConcreteState）：实现抽象状态接口，定义特定状态下环境类的行为，并负责状态之间的转换
状态模式实战：订单状态管理
让我们通过一个订单状态管理系统来深入理解状态模式。假设一个电商订单有以下状态流转：
- 待支付（PendingPayment）：可执行支付操作，支付后转为已支付状态
- 已支付（Paid）：可执行发货操作，发货后转为已发货状态
- 已发货（Shipped）：可执行确认收货操作，确认后转为已完成状态
- 已完成（Completed）：订单生命周期结束，无后续操作
步骤 1：创建抽象状态接口
首先定义订单状态的抽象接口，包含所有可能的操作：
// 订单状态抽象接口
public interface OrderState {
// 支付订单
void pay(OrderContext context);
// 发货
void ship(OrderContext context);
// 确认收货
void confirmReceipt(OrderContext context);
// 获取当前状态名称
String getStateName();
}
步骤 2：实现具体状态类
分别实现四种具体的订单状态，每个状态类负责处理该状态下的合法操作，并实现状态转换：
// 待支付状态
public class PendingPaymentState implements OrderState {
@Override
public void pay(OrderContext context) {
// 待支付状态可以执行支付操作，支付后转为已支付状态
System.out.println("订单支付成功");
context.setState(new PaidState());
}
@Override
public void ship(OrderContext context) {
// 待支付状态不能发货
System.out.println("错误：订单未支付，无法发货");
}
@Override
public void confirmReceipt(OrderContext context) {
// 待支付状态不能确认收货
System.out.println("错误：订单未支付，无法确认收货");
}
@Override
public String getStateName() {
return "待支付";
}
}
// 已支付状态
public class PaidState implements OrderState {
@Override
public void pay(OrderContext context) {
// 已支付状态不能重复支付
System.out.println("错误：订单已支付，无需重复支付");
}
@Override
public void ship(OrderContext context) {
// 已支付状态可以发货，发货后转为已发货状态
System.out.println("订单发货成功");
context.setState(new ShippedState());
}
@Override
public void confirmReceipt(OrderContext context) {
// 已支付状态（未发货）不能确认收货
System.out.println("错误：订单未发货，无法确认收货");
}
@Override
public String getStateName() {
return "已支付";
}
}
// 已发货状态
public class ShippedState implements OrderState {
@Override
public void pay(OrderContext context) {
// 已发货状态无需支付
System.out.println("错误：订单已发货，无需支付");
}
@Override
public void ship(OrderContext context) {
// 已发货状态不能重复发货
System.out.println("错误：订单已发货，无需重复发货");
}
@Override
public void confirmReceipt(OrderContext context) {
// 已发货状态可以确认收货，确认后转为已完成状态
System.out.println("订单已确认收货");
context.setState(new CompletedState());
}
@Override
public String getStateName() {
return "已发货";
}
}
// 已完成状态
public class CompletedState implements OrderState {
@Override
public void pay(OrderContext context) {
System.out.println("错误：订单已完成，无需支付");
}
@Override
public void ship(OrderContext context) {
System.out.println("错误：订单已完成，无需发货");
}
@Override
public void confirmReceipt(OrderContext context) {
System.out.println("错误：订单已完成，无需重复确认收货");
}
@Override
public String getStateName() {
return "已完成";
}
}
步骤 3：创建环境类
环境类（订单类）维护当前状态的引用，并将操作委托给当前状态对象：
// 订单环境类
public class OrderContext {
private String orderId;
private OrderState currentState;
// 初始化订单，默认状态为待支付
public OrderContext(String orderId) {
this.orderId = orderId;
this.currentState = new PendingPaymentState();
System.out.println("创建订单：" + orderId + "，当前状态：" + currentState.getStateName());
}
// 设置当前状态
public void setState(OrderState state) {
this.currentState = state;
System.out.println("订单状态变更为：" + currentState.getStateName());
}
// 支付订单（委托给当前状态）
public void pay() {
currentState.pay(this);
}
// 发货（委托给当前状态）
public void ship() {
currentState.ship(this);
}
// 确认收货（委托给当前状态）
public void confirmReceipt() {
currentState.confirmReceipt(this);
}
// 获取当前状态名称
public String getCurrentStateName() {
return currentState.getStateName();
}
}
步骤 4：客户端测试
创建客户端代码，模拟订单的状态流转过程：
public class Client {
public static void main(String[] args) {
// 创建订单（初始状态：待支付）
OrderContext order = new OrderContext("ORD-20230510-12345");
// 尝试发货（应该失败，因为还未支付）
order.ship();
// 执行支付（状态转为已支付）
order.pay();
// 再次尝试支付（应该失败）
order.pay();
// 执行发货（状态转为已发货）
order.ship();
// 执行确认收货（状态转为已完成）
order.confirmReceipt();
// 尝试再次发货（应该失败）
order.ship();
}
}
运行结果：
创建订单：ORD-20230510-12345，当前状态：待支付
错误：订单未支付，无法发货
订单支付成功
订单状态变更为：已支付
错误：订单已支付，无需重复支付
订单发货成功
订单状态变更为：已发货
订单已确认收货
订单状态变更为：已完成
错误：订单已完成，无需发货
状态模式与条件判断的对比
没有使用状态模式时，我们通常会用大量的if-else或switch-case来处理状态逻辑，比如这样：
// 不使用状态模式的订单类（存在大量条件判断）
public class BadOrder {
private String state; // pendingPayment, paid, shipped, completed
public void pay() {
if ("pendingPayment".equals(state)) {
System.out.println("订单支付成功");
state = "paid";
} else if ("paid".equals(state)) {
System.out.println("错误：订单已支付，无需重复支付");
} else if ("shipped".equals(state)) {
System.out.println("错误：订单已发货，无需支付");
} else if ("completed".equals(state)) {
System.out.println("错误：订单已完成，无需支付");
}
}
// 其他方法也存在类似的大量条件判断...
}
对比之下，状态模式的优势显而易见：
- 消除了冗长的条件判断语句，代码更清晰
- 将每个状态的行为封装在独立的类中，符合单一职责原则
- 新增状态只需添加新的状态类，符合开闭原则
- 状态转换逻辑集中在状态类中，便于维护和理解
状态模式的变种
根据状态转换逻辑的位置，状态模式有两种常见实现方式：
- 状态驱动的转换：状态转换逻辑在状态类中（如我们上面的示例），每个状态决定下一个状态
- 环境驱动的转换：状态转换逻辑在环境类中，环境类决定何时转换到哪个状态
// 环境驱动的转换示例（状态类不负责转换）
public class EnvironmentDrivenState implements OrderState {
@Override
public void pay(OrderContext context) {
System.out.println("订单支付成功");
// 状态转换由环境类决定，这里只做业务处理
}
// ...其他方法
}
// 环境类中处理状态转换
public class EnvironmentDrivenContext {
public void pay() {
currentState.pay(this);
// 环境类决定状态转换
if (currentState instanceof PendingPaymentState) {
setState(new PaidState());
}
}
}
状态模式的优缺点
优点
- 封装了状态转换规则，将状态相关的行为局部化
- 避免了过多的条件判断，使代码更清晰、更易维护
- 符合开闭原则，新增状态只需添加新的状态类
- 状态类之间可以相互独立，减少了类间依赖
缺点
- 类数量增加：每个状态都需要一个对应的类，可能导致类数量增多
- 状态转换逻辑分散：在状态驱动的实现中，状态转换逻辑分散在各个状态类中，可能难以跟踪整体状态流转
实际应用场景
状态模式在 Java 生态和实际开发中有很多典型应用：
- 有限状态机（FSM）：任何需要实现有限状态机的场景都适合使用状态模式
- UI 组件状态管理：如按钮的启用 / 禁用状态、窗口的最大化 / 最小化状态
- 订单系统：订单的各种状态流转管理
- 工作流引擎：流程节点之间的状态转换
- 线程状态管理：Java 线程的新建、就绪、运行、阻塞、死亡等状态转换
- TCP 连接状态：TCP 连接的建立、监听、同步、确认等状态管理
最佳实践与注意事项
- 状态数量适中时使用：如果状态数量极少（如只有 2-3 种），简单的条件判断可能比状态模式更简洁
- 状态转换逻辑清晰化：可以使用状态图来可视化状态转换关系，便于理解和维护
- 考虑状态的复用：相似的状态可以考虑复用同一个状态类
- 结合享元模式：如果有大量对象共享相同状态，可以结合享元模式减少对象创建
总结
状态模式通过将对象的状态封装成独立的状态类，使对象的行为能够随着状态的变化而动态改变，有效解决了包含大量状态判断的代码维护问题。
它特别适合以下场景：
- 对象的行为依赖于其状态，并且在不同状态下有不同的行为
- 代码中包含大量与状态相关的条件判断语句
- 需要频繁地添加或修改状态及状态相关的行为
掌握状态模式，能够帮助我们设计出更灵活、更易扩展、更易维护的状态驱动型系统，让对象的状态管理变得优雅而清晰。
