枚举类中声明abstract方法时，每个常量必须在{}内实现，编译器强制检查；本质是为各常量创建匿名子类，支持独立逻辑与字段，但不支持跨常量调用、方法重载或运行时扩展。
枚举类里声明 abstract 方法必须被每个常量实现
Java 编译器会强制检查：只要枚举类中声明了 abstract 方法，每个枚举常量就必须在自己的大括号 {} 内提供具体实现。漏掉任何一个，编译直接报错 java.lang.Enum 相关的“must implement”错误。
这不是可选语法糖，而是类型安全的核心保障——它把运行时可能出错的 switch 分支逻辑，提前锁死在编译期。
- 不能在枚举常量后加分号再写方法（比如
ADD; @Override public int apply(...) {...}），必须紧接{} -
abstract关键字写在方法声明上，不是写在枚举常量名前 - 枚举类本身不用加
abstract修饰符，哪怕它只含抽象方法
用大括号 {} 实现常量专属逻辑，不是重写普通方法
你看到的 ADD { @Override public int apply(...) { ... } } 这种写法，本质是为该枚举常量创建了一个匿名子类实例。它和继承 Enum 的关系是隐式的，但行为上等价于“每个常量都是独立的策略类”。
这意味着：不同常量之间完全隔离，互不影响；字段、局部变量、甚至 try-catch 块都可以各自定义。
- 不能在
{}外部访问该常量内部定义的变量（作用域限制） - 如果多个常量逻辑高度相似，优先考虑提取公共字段 + 构造器传参，而不是复制粘贴代码
- 不支持在
{}里调用另一个枚举常量的方法（比如SUBTRACT.apply(...)），会报 “cannot reference … before supertype constructor is called”
抽象方法参数和返回值必须完全一致
所有枚举常量实现的 apply(int a, int b)，签名必须和抽象方法声明一模一样：参数个数、类型顺序、返回类型都不能变。Java 不允许协变返回（除非是引用类型且子类更具体），也不允许参数类型宽泛化。
常见误操作是某个常量想多传一个上下文对象，结果改成 apply(int a, int b, Context ctx) —— 这会破坏契约，编译失败。
- 需要额外参数？把它作为枚举类私有字段，在构造器中传入，然后在
{}内复用 - 返回类型想用
Optional<integer></integer>替代int？可以，但所有常量都得统一改，且抽象方法声明也得同步更新 - 别试图靠重载解决差异：枚举里不允许两个同名但参数不同的
apply方法
别把抽象方法当成万能胶水
这种模式适合行为差异明确、常量数量固定、逻辑体量适中的场景。一旦某个常量的实现开始出现三层嵌套 if、调用外部服务、或需要状态管理，就该警觉了——这不是枚举该干的活。
此时更合理的做法是：把这个常量替换成一个真实策略类实例，通过工厂或依赖注入加载，让枚举退回到纯数据标识角色。
- 枚举无法在运行时新增常量，行为扩展硬编码在 class 文件里
- 单元测试时，你没法 mock 某个枚举常量的行为（因为它是 final 类型）
- IDE 调试时，
ADD.apply(1, 2)的调用栈会显示匿名类名，比如Operator$1，对排查不友好
复杂点在于：抽象方法把多态“藏”进了枚举结构里，初看简洁，但团队协作时容易忽略它背后仍是类继承体系。最容易被忽略的是——你以为在调用一个“方法”，其实每次都在触发一次隐式子类的实例方法分派。
