状态模式通过将状态建模为独立对象，使行为随状态改变而变化，其状态转换可由上下文控制、状态类驱动或使用状态转换表管理，在订单系统等复杂场景中能有效避免大量条件判断，提升可维护性和扩展性，适用于状态多且转换规则复杂的场景。
状态模式通过将对象的行为封装在不同的状态类中，使对象在内部状态改变时能够改变其行为，从而实现行为随状态变化的效果。它把与特定状态相关的行为局部化到对应的状态类中，避免了使用大量条件判断语句（如 if/else 或 switch），提升了代码的可维护性和扩展性。
状态模式如何管理状态转换
状态模式的核心是将“状态”本身建模为独立的类，每个状态类实现相同的状态接口，但提供不同的行为实现。对象的当前状态由一个状态实例表示，当状态需要改变时，对象将当前状态引用替换为新的状态实例。
状态转换的管理通常有以下几种方式：
-
由上下文（Context）控制状态转换
上下文对象持有当前状态，并在某些操作后根据业务逻辑决定切换到哪个新状态。状态类不直接创建下一个状态，而是通知上下文进行转换。 -
由状态类驱动状态转换
某些情况下，状态类在执行完自身逻辑后，主动要求上下文切换到下一个状态。此时状态类会调用上下文的方法来改变当前状态。 -
使用状态转换表
在上下文中维护一个映射表（如 Map），定义“当前状态 + 事件 → 新状态”的规则，通过查表实现自动转换，适用于状态和事件较多的场景。
行为随状态改变的实现方案
为了实现行为随状态改变，状态模式将每个状态下的行为封装到对应的状态类中。以下是关键实现思路：
-
定义统一的状态接口
所有具体状态类实现一个公共接口或抽象类，包含所有可能随状态变化的行为方法。 -
每个状态类实现自己的行为逻辑
不同状态下同一操作的行为不同，由对应的状态类各自实现。例如，“提交订单”在“待支付”状态下允许操作，在“已取消”状态下则抛出异常或提示无效。 -
上下文代理行为调用
上下文对象不直接实现状态相关行为，而是将请求委托给当前持有的状态对象处理。
示例场景：订单状态管理
假设订单有“待支付”、“已支付”、“已发货”、“已取消”四种状态，不同状态下对“支付”、“发货”、“取消”等操作的响应不同。
// 状态接口 interface OrderState { void pay(OrderContext context); void ship(OrderContext context); void cancel(OrderContext context); } // 待支付状态 class PendingPaymentState implements OrderState { public void pay(OrderContext context) { System.out.println("支付成功"); context.setState(new PaidState()); } public void ship(OrderContext context) { System.out.println("无法发货，订单尚未支付"); } public void cancel(OrderContext context) { System.out.println("订单已取消"); context.setState(new CancelledState()); } } // 已支付状态 class PaidState implements OrderState { public void pay(OrderContext context) { System.out.println("订单已支付，无需重复支付"); } public void ship(OrderContext context) { System.out.println("已发货"); context.setState(new ShippedState()); } public void cancel(OrderContext context) { System.out.println("订单已支付，无法取消"); } } // 上下文类 class OrderContext { private OrderState state; public OrderContext() { this.state = new PendingPaymentState(); } public void setState(OrderState state) { this.state = state; } public void pay() { state.pay(this); } public void ship() { state.ship(this); } public void cancel() { state.cancel(this); } }
在这个例子中：
- 每个状态类定义了在该状态下对操作的响应。
- 上下文将操作请求委派给当前状态对象。
- 状态转换通过
setState()
实现，可以发生在状态内部或上下文中。
优势与适用场景
-
避免复杂的条件判断
不需要在每个方法中写 if-else 判断当前状态，逻辑更清晰。 -
易于扩展新状态
增加新状态只需添加新的状态类，符合开闭原则。 -
行为与状态解耦
每个状态的行为独立封装，便于测试和维护。 -
适合状态较多、转换规则复杂的场景
如订单系统、工作流引擎、游戏角色状态机等。
但也要注意：如果状态少、逻辑简单，使用状态模式反而会增加复杂度。
基本上就这些。状态模式的关键在于把“状态”当成对象，让对象的行为随着状态对象的更换而自然变化，转换由上下文或状态自身控制，结构清晰，扩展性强。
评论（已关闭）
评论已关闭