Record + 密封接口构建强类型状态机

本文揭示了如何利用Java 21+的sealed interface、record和记录模式构建真正强类型、编译期安全的状态机——通过显式声明permits列表锁定所有合法状态、用领域驱动的不可变record建模每个状态、配合无default分支的switch表达式实现100%穷尽检查，从而在编译阶段杜绝非法状态、遗漏处理和运行时类型错误，这不仅是Java对代数数据类型（ADT）最务实的落地实践，更是一场从“容忍错误”到“强制正确”的工程范式升级。

直接说结论：用 sealed interface 定义状态机的顶层契约，每个具体状态用 record 实现，再配合 switch + 记录模式（Java 21+），就能在编译期锁死所有状态分支、杜绝漏处理、避免非法状态注入——这是目前 Java 最接近代数数据类型（ADT）的落地方式。

密封接口必须声明 permits 且子类与之同模块

不写 permits，编译器不会报错但会推导“直接实现类”，这在多模块或重构时极易失效；更危险的是，如果子类不在同一模块（或未显式导出），JVM 运行时可能因模块限制导致 NoClassDefFoundError。

• permits 列表必须显式写出全部合法实现类，不能留空或用通配符
• 所有 record 实现类必须和密封接口在同一个模块中，且该模块需在 module-info.java 中导出它们
• 若用 sealed abstract class 替代接口，子类仍需用 final、sealed 或 non-sealed 显式修饰——但接口更轻量，更适合纯状态建模

Record 字段命名要反映业务语义，而非技术容器

比如状态为 Processing，不要定义 record Processing(String id, long timestamp)，而应写 record Processing(OrderId id, Instant startedAt)。后者让字段类型自带约束（OrderId 是值对象，不可被 String 随意赋值），也使后续模式匹配更安全。

• 避免裸类型：用领域专用类型替代 String、long 等原始类型作为 record 字段
• record 构造参数顺序要稳定：一旦发布，调整顺序会导致二进制不兼容（即使源码兼容）
• 不建议在 record 中加逻辑方法（如 isValid()）——状态合法性应由状态转换函数（transition function）统一校验，而非分散在各 record 内

Switch 表达式必须覆盖全部 permits 类型，否则编译失败

这是密封接口 + record 组合最硬的保障点。只要用了 switch (state)，且 state 类型是密封接口，JDK 就会强制你列出所有 permits 子类，漏一个就编译不过。

• Java 21+ 支持记录模式，可直接解构字段：case Processing(OrderId id, Instant at) -> ...
• 不要加 default 分支——加了反而绕过穷尽检查，失去类型安全价值
• 若需 fallback 行为（如日志兜底），用 throw new IllegalStateException("Unexpected state: " + state)，编译器仍能验证该分支永不执行

状态迁移函数必须返回密封接口类型，禁止返回 Object 或泛型通配符

常见错误是把 transition 方法写成 T next(State current)，这会让类型信息在调用链中丢失，后续 switch 失去穷尽性保证。

• 迁移函数签名应为 State transition(State current, Event event)，其中 State 是密封接口
• 每个 case 分支必须返回明确的 record 实例，例如 case Pending p -> new Processing(p.orderId(), Instant.now())
• 避免在 record 中存可变引用（如 List），若必须持有集合，用 ImmutableList 或 List.copyOf(...) 封装

真正难的不是语法，而是设计时是否愿意把“所有可能状态”一次性列全——permits 不是装饰，是契约；record 不是语法糖，是不可变性的强制声明；而 switch 的编译期检查，只对严格遵循这两条的人生效。

本篇关于《Record + 密封接口构建强类型状态机》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！