1. 状态模式基础认知
第一次接触状态模式是在重构一个电商订单系统时。当时系统里充斥着大量if-else判断订单状态的代码，每次新增状态都要在所有相关方法里添加分支逻辑。这种"面条式"代码让我深刻意识到——是时候引入状态模式了。
状态模式属于行为型设计模式，它允许对象在内部状态改变时改变其行为，使对象看起来像是修改了它的类。这个定义听起来有些抽象，我们可以用现实生活中的电梯来类比：
- 电梯有开门、关门、运行、停止等状态
- 在不同状态下，按下同一按钮会产生不同反应
- 比如运行状态下按开门按钮无效，而停止状态下按开门按钮会触发开门动作
状态模式的核心思想就是把状态抽象为独立类，将状态相关的行为封装到对应类中。这样当新增状态时，只需要新增状态类而不用修改原有代码，完美符合开闭原则。
2. 模式结构与Java实现
2.1 经典UML结构解析
状态模式包含三个核心角色：
- Context（环境类）：维护当前状态实例，定义客户感兴趣的接口
- State（抽象状态）：声明状态对应的方法
- ConcreteState（具体状态）：实现状态对应的行为
用Java代码表示典型结构：
java复制// 抽象状态
interface State {
void handle(Context context);
}
// 具体状态A
class ConcreteStateA implements State {
@Override
public void handle(Context context) {
System.out.println("当前是状态A");
context.setState(new ConcreteStateB());
}
}
// 具体状态B
class ConcreteStateB implements State {
@Override
public void handle(Context context) {
System.out.println("当前是状态B");
context.setState(new ConcreteStateA());
}
}
// 环境类
class Context {
private State state;
public Context(State state) {
this.state = state;
}
public void setState(State state) {
this.state = state;
}
public void request() {
state.handle(this);
}
}
2.2 订单状态实战案例
假设我们要实现电商订单状态流转：
- 待支付 -> 已支付
- 已支付 -> 待发货
- 待发货 -> 已发货
- 已发货 -> 已完成
传统if-else实现会是这样：
java复制class Order {
private String state;
public void pay() {
if ("待支付".equals(state)) {
state = "已支付";
} else {
throw new IllegalStateException();
}
}
public void ship() {
if ("已支付".equals(state)) {
state = "待发货";
} else if ("待发货".equals(state)) {
state = "已发货";
} else {
throw new IllegalStateException();
}
}
// 其他方法...
}
改用状态模式重构后：
java复制// 抽象状态
interface OrderState {
void pay(Order order);
void ship(Order order);
void receive(Order order);
}
// 具体状态：待支付
class UnpaidState implements OrderState {
@Override
public void pay(Order order) {
System.out.println("支付成功");
order.setState(new PaidState());
}
@Override
public void ship(Order order) {
throw new IllegalStateException("未支付不能发货");
}
// 其他方法...
}
// 环境类
class Order {
private OrderState state;
public Order() {
this.state = new UnpaidState();
}
public void setState(OrderState state) {
this.state = state;
}
public void pay() {
state.pay(this);
}
// 其他委托方法...
}
3. 模式优势与适用场景
3.1 与传统条件语句对比
状态模式相比if-else/switch的优势：
- 符合单一职责原则：每个状态逻辑封装在独立类中
- 符合开闭原则：新增状态不需修改现有代码
- 可维护性：状态转换逻辑更清晰
- 可测试性：每个状态可以单独测试
经验法则：当发现一个类中有大量状态判断条件，且每个条件下行为差异较大时，就应该考虑使用状态模式。
3.2 典型应用场景
- 工作流引擎：如审批流程、订单流程
- 游戏开发：角色状态管理（站立、跑动、跳跃等）
- 硬件控制：设备状态管理（开机、关机、待机）
- UI交互：控件不同状态下的行为（禁用、只读、编辑）
4. 高级应用与优化技巧
4.1 状态共享与享元模式
某些情况下，状态对象可以共享（无实例变量时）。这时可以结合享元模式：
java复制class StateFactory {
private static final Map<String, OrderState> states = new HashMap<>();
static {
states.put("unpaid", new UnpaidState());
states.put("paid", new PaidState());
// 其他状态...
}
public static OrderState getState(String key) {
return states.get(key);
}
}
4.2 状态转换的集中管理
当状态转换逻辑复杂时，可以引入专门的状态转换器：
java复制class StateTransition {
private static final Map<Class<?>, Map<String, Class<?>>> rules = new HashMap<>();
static {
Map<String, Class<?>> unpaidTrans = new HashMap<>();
unpaidTrans.put("pay", PaidState.class);
rules.put(UnpaidState.class, unpaidTrans);
// 其他转换规则...
}
public static State transition(State current, String action) {
Map<String, Class<?>> trans = rules.get(current.getClass());
Class<?> target = trans.get(action);
if (target != null) {
try {
return (State) target.newInstance();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
throw new IllegalStateException();
}
}
5. 常见问题与解决方案
5.1 状态爆炸问题
当状态过多时，会导致类数量膨胀。解决方案：
- 合并相似状态
- 使用状态表驱动
- 考虑是否更适合用状态机实现
5.2 上下文信息传递
有时状态处理需要访问上下文数据。两种实现方式：
- 将上下文作为参数传递给状态方法（前文示例方式）
- 状态对象持有上下文引用（需注意循环引用）
5.3 线程安全问题
如果状态对象被多个上下文共享：
- 确保状态类是无状态的（无成员变量）
- 或使用线程安全容器管理状态
- 或为每个上下文创建独立状态实例
6. 模式变体与相关模式
6.1 状态表驱动实现
对于简单状态机，可以用枚举+表驱动：
java复制enum OrderState {
UNPAID {
@Override
public OrderState next(String action) {
if ("pay".equals(action)) return PAID;
throw new IllegalStateException();
}
},
PAID {
@Override
public OrderState next(String action) {
if ("ship".equals(action)) return SHIPPED;
throw new IllegalStateException();
}
};
public abstract OrderState next(String action);
}
6.2 与策略模式的区别
状态模式和策略模式结构相似但意图不同：
- 策略模式：客户端主动选择不同算法
- 状态模式：状态转换由内部条件触发，客户端不感知
6.3 状态模式与状态机
复杂场景下可以考虑使用专门的状态机框架（如Spring State Machine），它们提供：
- 可视化状态图
- 持久化支持
- 分布式状态管理
- 事件监听机制
7. 测试策略与最佳实践
7.1 单元测试要点
测试状态模式时重点关注：
- 每个状态类的行为是否正确
- 状态转换是否符合预期
- 非法操作是否抛出适当异常
示例测试用例：
java复制@Test
public void testUnpaidToPaid() {
Order order = new Order();
order.pay();
assertTrue(order.getState() instanceof PaidState);
}
@Test(expected = IllegalStateException.class)
public void testInvalidTransition() {
Order order = new Order();
order.ship(); // 未支付直接发货应该报错
}
7.2 日志与调试技巧
在状态模式中添加日志的建议：
- 在环境类中记录状态转换
- 为每个状态类添加toString()
- 使用MDC（Mapped Diagnostic Context）跟踪当前状态
java复制class Order {
private static final Logger log = LoggerFactory.getLogger(Order.class);
public void setState(OrderState state) {
log.info("状态变更：{} -> {}", this.state, state);
this.state = state;
}
}
7.3 性能优化建议
- 避免在状态处理方法中创建新状态实例（可以复用）
- 对于频繁转换的场景，考虑使用状态池
- 将状态类设计为不可变对象
8. 实际项目经验分享
在电商平台项目中，我们使用状态模式管理订单生命周期时遇到了几个典型问题：
-
逆向流程处理（如退款导致状态回退）：
- 解决方案：建立双向状态转换图
- 为每个逆向操作定义明确的前置条件
-
分布式环境下的状态一致性问题：
- 采用乐观锁控制并发修改
- 关键状态变更通过事件日志记录
-
长流程导致的上下文膨胀：
- 将大状态机拆分为多个小状态机
- 使用备忘录模式保存中间状态
一个实用的技巧是为状态类添加描述信息，便于前端展示和日志记录：
java复制interface OrderState {
String getDescription();
String getColor();
}
class ShippedState implements OrderState {
@Override
public String getDescription() {
return "已发货";
}
@Override
public String getColor() {
return "blue";
}
}
状态模式的学习曲线相对平缓，但要在实际项目中用好，关键是要识别出真正的"状态"是什么。有些开发者容易把业务数据和状态混淆，导致过度设计。我的经验法则是：只有当对象的行为需要随某个条件发生本质变化时，才需要使用状态模式。