共 2 篇相关文章
这篇文章探讨的是如何对经典的状态模式进行一个实用的小改进。作者从实践中发现，传统状态模式虽然清晰，但在状态流转逻辑上有时显得笨重——每个状态都需要实现完整的接口，哪怕有些状态之间的转换逻辑是重复或简单的。 为此，作者提出了一种更轻量的实现方式：将状态转换的逻辑集中到一个“状态机”中进行管理，让具体的状态类只负责定义在该状态下可执行的行为。这样做的核心好处是，状态流转的规则变得集中且一目了然，新增或修改状态转换时只需改动一处，而不必深入到各个分散的状态类里去排查。 这种改进尤其适用于状态数量较多、但转换路径存在规律或需要灵活配置的场景。它本质上是将“策略”与“路由”做了解耦，让代码的复杂度得到了更好的控制，最终使得整个状态管理模块更易于维护和扩展。
这篇讲的是经典设计模式中容易被混淆的“双胞胎”——状态模式与策略模式。它们都通过多态将操作分派到一组类中，代码结构几乎一模一样，但作者从意图和应用场景上切入，点明了核心差异：状态模式关注的是对象内部状态的流转与行为切换，而策略模式则聚焦于外部算法或行为的选择与替换。 文章通过具体代码对比指出，虽然两者都依赖接口和实现类，但状态模式的状态对象通常持有上下文引用并能自主触发状态变更，形成一条隐形的“状态链”；策略模式的策略对象则更加独立，由客户端在运行时显式选定并注入，更像可插拔的“算法插件”。这种细微的设计思想差别，决定了前者更适合解决对象生命周期中复杂的内在状态管理问题（如订单流程），后者则擅长应对同一问题下多种可选算法或规则的灵活切换（如支付方式选择）。 理解这种“形似而神异”的区别，能帮助我们在设计时避免误用，让模式真正为业务逻辑服务。
