h5打开以查看为什么需要状态模式？假设正在实现电商订单系统，订单有五种状态：待支付、已支付、已发货、已完成、已取消。每种状态下可执行的操作都不一样——待支付可以支付、可以取消；已发货只能确认收货；已完成不能再动。没有状态模式的时候，代码大概长这样：class Order { private String status = "PENDING"; public void pay() { if ("PENDING".equals(status)) { System.out.println("支付成功"); status = "PAID"; } else if ("PAID".equals(status)) { throw new RuntimeException("已支付，不能重复支付"); } else if ("SHIPPED".equals(status)) { throw new RuntimeException("已发货，不能支付"); } else if ("CANCELLED".equals(status)) { throw new RuntimeException("已取消，不能支付"); } // ... } public void ship() { // 同样的 if-else 判断五种状态 ... } public void confirm() { // 同样的 if-else 判断五种状态 ... } public void cancel() { // 同样的 if-else 判断五种状态 ... } }问题一目了然：状态判断和业务逻辑混在一起。5 种状态 × 4 个操作 = 20 个条件分支散落各处。新增一个"退货中"状态？四个方法都要改一遍。想搞清楚"已支付"状态能干什么？得翻遍所有方法找带"PAID"的分支。换一种思路："当前是什么状态"应该由一个专门的对象来承担，而不是由字符串常量来标记。状态模式解决的就是这个问题——把每种状态封装成一个类，让状态自己决定"我这个状态下能做什么、做完之后变成什么"，Order只负责持有当前状态并转发调用。概念状态模式（State Pattern）是一种行为型设计模式，核心思想是允许一个对象在内部状态改变时改变它的行为，使对象看起来好像修改了它的类型。从理论上看，状态模式是有限状态机（Finite State Machine, FSM）的面向对象实现：FSM 描述"一组状态、若干事件、以及状态之间的转换规则"，状态模式则把每个状态变成一个对象、把转换规则封装进状态类内部。建立这个对应关系后，遇到"状态机"一词便能直接映射到状态模式，不会当作陌生概念。可以把它想象成红绿灯：红灯状态下车辆要停下，绿灯状态下允许通行，黄灯状态下要减速——完全不同的行为，但对外都是"同一个红绿灯"。路口本身不需要有一大堆if (color == red) ...的逻辑，只要"当前是哪个灯就执行那个灯的规则"，切换灯色时行为自然跟着变。状态模式涉及三个角色：Context（上下文）：持有一个当前状态的引用，把行为委托给当前状态对象，并提供状态切换的入口State（状态接口）：定义 Context 在某一状态下可能执行的所有行为接口ConcreteState（具体状态）：实现状态接口，负责该状态下的具体行为，并决定操作完成后转向哪个状态图中各类之间的关系：Context持有一个State引用，request方法把调用委托给当前状态。ConcreteStateA和ConcreteStateB各自实现handle方法，处理当前状态下的行为并返回下一个状态。状态之间通过"返回新状态对象"完成转换——ConcreteStateA的handle可能返回ConcreteStateB的实例，Context 用返回值更新自身的当前状态。实现状态模式的落地有两种常见变体：一种是 GoF 原书的"状态类持有 Context 引用，主动调用 Context 的setState切换"；另一种更现代的做法是"状态类的方法直接返回下一个状态对象，由 Context 根据返回值更新"。第二种变体更简洁——状态类不需要持有 Context 引用，耦合更彻底地降到零。本文主推这种变体。基础实现定义State接口，声明handle方法返回State——这个返回值就是操作完成后要转向的下一个状态。ConcreteStateA和ConcreteStateB各自实现handle，处理完自身逻辑后返回对方的实例。Context持有当前状态，在request方法中调用状态的handle并用返回值更新自身状态。// State：状态接口，方法返回下一个状态 interface State { State handle(); } // ConcreteStateA：具体状态 A class ConcreteStateA implements State { public State handle() { System.out.println("状态 A 的处理逻辑"); return new ConcreteStateB(); // 返回下一个状态 } } // ConcreteStateB：具体状态 B class ConcreteStateB implements State { public State handle() { System.out.println("状态 B 的处理逻辑"); return new ConcreteStateA(); } } // Context：上下文 class Context { private State state; public Context(State initialState) { this.state = initialState; } public void request() { this.state = state.handle(); // 用返回值更新当前状态 } } // 客户端 class Client { public static void main(String[] args) { Context context = new Context(new ConcreteStateA()); context.request(); // 状态 A 的处理逻辑 → 切换到 B context.request(); // 状态 B 的处理逻辑 → 切换回 A } }角色对照：Context（上下文）：Context，持有当前状态并转发调用State（状态接口）：State，声明handle返回下一个状态ConcreteState（具体状态）：ConcreteStateA、ConcreteStateB关键点：状态之间的转换关系完全封装在状态类内部——ConcreteStateA.handle明确知道自己下一个要变成Concre
h5打开以查看为什么需要状态模式？假设正在实现电商订单系统，订单有五种状态：待支付、已支付、已发货、已完成、已取消。每种状态下可执行的操作都不一样——待支付可以支付、可以取消；已发货只能确认收货；已完成不能再动。没有状态模式的时候，代码大概长这样：class Order { private String status = "PENDING"; public void pay() { if ("PENDING".equals(status)) { System.out.println("支付成功"); status = "PAID"; } else if ("PAID".equals(status)) { throw new RuntimeException("已支付，不能重复支付"); } else if ("SHIPPED".equals(status)) { throw new RuntimeException("已发货，不能支付"); } else if ("CANCELLED".equals(status)) { throw new RuntimeException("已取消，不能支付"); } // ... } public void ship() { // 同样的 if-else 判断五种状态 ... } public void confirm() { // 同样的 if-else 判断五种状态 ... } public void cancel() { // 同样的 if-else 判断五种状态 ... } }问题一目了然：状态判断和业务逻辑混在一起。5 种状态 × 4 个操作 = 20 个条件分支散落各处。新增一个"退货中"状态？四个方法都要改一遍。想搞清楚"已支付"状态能干什么？得翻遍所有方法找带"PAID"的分支。换一种思路："当前是什么状态"应该由一个专门的对象来承担，而不是由字符串常量来标记。状态模式解决的就是这个问题——把每种状态封装成一个类，让状态自己决定"我这个状态下能做什么、做完之后变成什么"，Order只负责持有当前状态并转发调用。概念状态模式（State Pattern）是一种行为型设计模式，核心思想是允许一个对象在内部状态改变时改变它的行为，使对象看起来好像修改了它的类型。从理论上看，状态模式是有限状态机（Finite State Machine, FSM）的面向对象实现：FSM 描述"一组状态、若干事件、以及状态之间的转换规则"，状态模式则把每个状态变成一个对象、把转换规则封装进状态类内部。建立这个对应关系后，遇到"状态机"一词便能直接映射到状态模式，不会当作陌生概念。可以把它想象成红绿灯：红灯状态下车辆要停下，绿灯状态下允许通行，黄灯状态下要减速——完全不同的行为，但对外都是"同一个红绿灯"。路口本身不需要有一大堆if (color == red) ...的逻辑，只要"当前是哪个灯就执行那个灯的规则"，切换灯色时行为自然跟着变。状态模式涉及三个角色：Context（上下文）：持有一个当前状态的引用，把行为委托给当前状态对象，并提供状态切换的入口State（状态接口）：定义 Context 在某一状态下可能执行的所有行为接口ConcreteState（具体状态）：实现状态接口，负责该状态下的具体行为，并决定操作完成后转向哪个状态图中各类之间的关系：Context持有一个State引用，request方法把调用委托给当前状态。ConcreteStateA和ConcreteStateB各自实现handle方法，处理当前状态下的行为并返回下一个状态。状态之间通过"返回新状态对象"完成转换——ConcreteStateA的handle可能返回ConcreteStateB的实例，Context 用返回值更新自身的当前状态。实现状态模式的落地有两种常见变体：一种是 GoF 原书的"状态类持有 Context 引用，主动调用 Context 的setState切换"；另一种更现代的做法是"状态类的方法直接返回下一个状态对象，由 Context 根据返回值更新"。第二种变体更简洁——状态类不需要持有 Context 引用，耦合更彻底地降到零。本文主推这种变体。基础实现定义State接口，声明handle方法返回State——这个返回值就是操作完成后要转向的下一个状态。ConcreteStateA和ConcreteStateB各自实现handle，处理完自身逻辑后返回对方的实例。Context持有当前状态，在request方法中调用状态的handle并用返回值更新自身状态。// State：状态接口，方法返回下一个状态 interface State { State handle(); } // ConcreteStateA：具体状态 A class ConcreteStateA implements State { public State handle() { System.out.println("状态 A 的处理逻辑"); return new ConcreteStateB(); // 返回下一个状态 } } // ConcreteStateB：具体状态 B class ConcreteStateB implements State { public State handle() { System.out.println("状态 B 的处理逻辑"); return new ConcreteStateA(); } } // Context：上下文 class Context { private State state; public Context(State initialState) { this.state = initialState; } public void request() { this.state = state.handle(); // 用返回值更新当前状态 } } // 客户端 class Client { public static void main(String[] args) { Context context = new Context(new ConcreteStateA()); context.request(); // 状态 A 的处理逻辑 → 切换到 B context.request(); // 状态 B 的处理逻辑 → 切换回 A } }角色对照：Context（上下文）：Context，持有当前状态并转发调用State（状态接口）：State，声明handle返回下一个状态ConcreteState（具体状态）：ConcreteStateA、ConcreteStateB关键点：状态之间的转换关系完全封装在状态类内部——ConcreteStateA.handle明确知道自己下一个要变成Concre
