Java枚举类实现状态机实战：利用对象化思维简化复杂变量逻辑

Ja va枚举实现状态机，核心不是“把状态列出来”，而是让每个状态自己回答：“我收到这个事件，能变成谁？”——用对象化思维把状态当作有行为的主体，而不是被动的数据容器。这其实是一种设计思维的转变：从“我怎么判断状态转移”变成“每个状态自己告诉我它能怎么变”。

状态即对象：每个枚举值自主决定转移逻辑

传统写法把所有判断堆在外部 service 里，比如：
if (status == CREATED && event == PAY) return PAID;
这种代码随状态和事件增多迅速失控，维护成本直线上升。而枚举天然支持为每个常量定制行为，关键在于：

• 声明抽象方法（如 transition(Event e) 或 approve(Context c)），强制子类实现
• CREATED、PAID 等每个枚举实例用自己的重写逻辑处理事件，不查表、不遍历，事件分发变成了多态调用
• 终态（如 CANCELLED、COMPLETED）可不重写方法，调用时直接抛 AbstractMethodError，编译期就暴露非法操作——这种“编译期保护”远比运行时排查来得高效

转移规则显式化：拒绝隐式默认和静默失败

常见的误区是依赖 switch + default 分支兜底，或者返回 this / null 来掩盖问题。这些做法本质上是在“容错”，而不是在设计。正确做法应该是：

• 每个 transition() 方法只响应它允许的事件，其余一律抛 IllegalStateException，并带清晰提示如 “Cannot SHIP from CANCELLED”
• 不依赖 ordinal() 判断顺序——重构时调整枚举位置会导致逻辑错乱，这种隐式依赖是事故的温床
• 不把业务动作（如发消息、扣库存）塞进枚举里：状态机只管“能不能变”，不变“变了之后做什么”。职责分离是状态机设计的第一原则

结构清晰、扩展无痛：新增状态只需三步

当业务需要加一个“待人工复核”状态时，流程简单到令人舒适：

• 在枚举中添加新常量 AWAITING_REVIEW
• 重写 transition(Event)，明确它接受哪些事件（如 APPROVE、REJECT）
• 其他已有状态、服务类、测试用例完全不用动——新增状态不会对现有逻辑造成任何冲击

这种扩展方式真正做到了“开闭原则”：对扩展开放，对修改关闭。

警惕常见误用：枚举不是万能容器

必须清醒认识到，枚举实例是全局单例，天生不适合存可变状态：

• ❌ 不要在枚举里定义 private int retryCount —— 所有订单共享同一计数器，后果可想而知
• ❌ 不要让枚举持有复杂业务对象（如 Service 引用），这会破坏纯状态职责，让枚举变成“四不像”
• ✅ 正确做法：状态流转结果由外部服务根据 fromState.transition(e) 返回值触发对应动作，枚举只负责“能不能变”的判断

把握住这个边界，枚举状态机才能真正成为你手中简洁、可靠且易于维护的工具。