枚举通过抽象方法实现强制多态，每个常量必须提供具体实现，支持参数、返回值和异常；结合私有构造器可携带状态元数据，适用于逻辑差异大或需扩展的状态驱动场景，提升安全性与可维护性。
直接用抽象方法让每个枚举值“自带行为”，比写一堆 if-else 或维护策略映射表更清晰、更安全、也更容易扩展。
抽象方法是强制多态的天然载体
在枚举类中声明一个没有方法体的方法（不写 abstract 也能生效），编译器就会要求每个枚举常量必须用大括号 { } 提供具体实现。这不是可选项，而是编译期强约束。
- 方法可以带参数、有返回值、声明异常，和普通抽象方法完全一致
- 枚举类本身不能显式声明为 abstract，但语义上就是抽象的
- 每个常量的实现体写在它后面的大括号里，比如 PAID { public String handle() { ... } }
- 调用时直接通过枚举实例调用，例如 OrderStatus.PAID.canRefund()，无需判断类型
结合字段与构造器，让行为有据可依
纯抽象方法适合逻辑差异大的场景；若还需携带状态元数据（如状态码、提示语、图标路径），就和私有构造器配合使用。
- 在枚举中定义 private final int code 和 private final String desc 等字段
- 每个常量通过 PAID(201, "已支付") { ... } 初始化字段
- 抽象方法体内可直接访问 this.code 或 this.desc，做条件判断或拼接返回值
- 例如：在 SHIPPED 的 generateLogistics() 实现里，用 this.code 调用对应物流接口
典型业务场景：状态驱动的动作封装
把“该状态能做什么”这件事，锁死在枚举内部，上层代码彻底无感。
- PENDING 实现 canCancel() 返回 true，generateLogistics() 抛 IllegalStateException
- PAID 允许 requestRefund()，但拒绝 ship()
- DELIVERED 只开放 submitReview() 和 applyAftersale()
- 服务层只需调用 order.getStatus().canCancel()，不用 switch，也不用查配置表
注意适用边界，避免过度设计
抽象方法不是银弹，用对地方才真正提效。
- 行为逻辑极简单（如只返回固定字符串）→ 直接用字段 + getter 更轻量
- 逻辑涉及校验、计算、外部调用，或未来大概率新增状态 → 抽象方法是最自然的解耦方式
- 不增加运行时开销，JVM 对枚举方法调用有专门优化
- 真正价值在于把“变化点”收拢到枚举内部，让调用方永远面对同一接口
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
