状态模式（State Pattern）是一种非常巧妙的行为型设计模式。它的核心思想可以用一句话概括：当一个对象的内部状态发生改变时，它的行为也跟着改变。
听起来有点抽象？其实它最厉害的地方在于，它让对象看起来就像是修改了它的类一样。这通常是因为我们将"状态"封装成了独立的类。
为了帮你彻底理解，我将从核心逻辑、代码结构、优缺点到实际应用为你详细拆解。
1. 核心逻辑：告别"面条代码"
在没有使用状态模式的传统编程中，我们通常会用大量的 if-else 或 switch-case 语句来判断对象的状态，并执行不同的逻辑46。
例如，一个订单对象可能有"待支付"、"已支付"、"已发货"等状态。如果用传统方式写，代码可能会长这样：
java
if (state == "待支付") {
// 执行支付逻辑
} else if (state == "已支付") {
// 执行发货逻辑
} else if ... // 后面可能还有几十行随着状态增多，这段代码会变得极其臃肿、难以维护（俗称"面条代码"）。
状态模式的解法是：
把每一个状态都封装成一个独立的类。每个类只负责自己状态下的行为。环境类（Context）不需要知道当前是什么状态，它只需要把请求"委托"给当前的状态对象去处理即可。
2. 核心角色
状态模式通常包含以下三个角色：
- Context（环境类/上下文）：
它是用户直接打交道的类。
它持有一个 State 接口的引用。
它将状态相关的请求委托给当前的状态对象来处理。
- State（抽象状态类）：
定义了一个接口，封装了与 Context 状态相关的行为。
- ConcreteState（具体状态类）：
实现 State 接口。
每一个子类实现一个与 Context 状态相关的行为（例如 PendingPaymentState、PaidState）。
3. 代码示例（简化版）
我们继续用订单的例子来演示：
第一步：定义状态接口
java
// 抽象状态接口
public interface OrderState {
void pay(); // 支付
void ship(); // 发货
}第二步：实现具体状态
java
// 待支付状态
public class PendingPaymentState implements OrderState {
@Override
public void pay() {
System.out.println("订单支付成功");
// 这里可以改变环境类的状态为"已支付"
}
@Override
public void ship() {
System.out.println("错误：请先支付订单");
}
}
// 已支付状态
public class PaidState implements OrderState {
@Override
public void pay() {
System.out.println("错误：订单已支付");
}
@Override
public void ship() {
System.out.println("订单发货成功");
}
}第三步：环境类（订单）
java
public class Order {
private OrderState currentState;
// 构造函数，默认为待支付状态
public Order() {
this.currentState = new PendingPaymentState();
}
// 委托给状态对象处理
public void pay() {
currentState.pay();
}
public void ship() {
currentState.ship();
}
// 提供给状态类修改自身状态的方法
public void setState(OrderState state) {
this.currentState = state;
}
}第四步：客户端调用
java
Order order = new Order();
order.ship(); // 输出：错误：请先支付订单
order.pay(); // 输出：订单支付成功
order.ship(); // 此时状态已变，输出：订单发货成功4. 优缺点分析
✅ 优点：
封装性好：将特定状态的行为局部化，符合"单一职责原则"。
消除条件语句：去掉了庞大的 if-else 或 switch，代码结构更清晰。
易于扩展：如果要增加新的状态，只需要新增一个具体状态类，无需修改现有代码（开闭原则）。
❌ 缺点：
类数量增多：每一个状态都要一个类，如果状态很多，系统类的数量会急剧增加。
切换逻辑复杂：状态之间的转换逻辑（从A状态怎么跳到B状态）如果处理不好，可能会导致代码混乱。有时需要在状态类内部维护对 Context 的引用，或者使用状态机来管理，增加了复杂度。
5. 适用场景
当你遇到以下情况时，应该优先考虑状态模式：
行为依赖状态：一个对象的行为取决于它的状态，并且状态在运行时经常改变。
复杂条件判断：代码中包含庞大的多分支 if-else 或 switch-case 语句，这些分支逻辑非常复杂。
状态流转明确：对象有明确的生命周期或状态流转路径（如：开始 -> 运行 -> 暂停 -> 结束）。
常见案例：
订单系统（待支付、已支付、退款中、已完成）。
游戏开发（角色的行走、攻击、防御、死亡状态）。
工作流引擎（任务的待处理、处理中、已完成）。
UI 控件（按钮的可用、禁用、按下状态）