Java 17 Sealed Classes：提升代码安全性与可维护性的新特性

Java 17作为最新的长期支持（LTS）版本，引入了多项旨在提升开发者效率和代码质量的特性，其中Sealed Classes（密封类）尤为引人注目。这一特性通过允许类或接口的作者明确声明哪些其他类或接口可以扩展或实现它们，为构建更安全、更清晰、更易于维护的领域模型提供了强有力的工具。

Sealed Classes的基本概念与语法

Sealed Classes的核心目标是限制类的层次结构。在传统的Java继承模型中，一个类只要不是final的，就可以被任何类继承。这种开放性虽然灵活，但在设计需要精确控制继承关系的领域模型时，往往会带来不确定性。Sealed Classes通过引入`sealed`、`permits`和`non-sealed`关键字来解决这一问题。一个密封类使用`sealed`修饰符声明，并通过`permits`子句明确列出允许扩展它的子类。这些子类必须直接继承该密封类，并且自身必须是final、sealed或non-sealed的。non-sealed类虽然继承自密封类，但它 itself 重新开放了继承的可能性。

如何提升代码安全性

Sealed Classes通过编译时的严格检查显著提升了代码的安全性。编译器会强制验证permits子句中声明的所有类是否都存在，并且它们是否正确地扩展了密封类。更重要的是，当在switch表达式（与Java 17的Pattern Matching for switch结合使用时）中处理密封类层次结构时，编译器能够进行 exhaustiveness（穷尽性）检查。这意味着编译器可以确保所有可能的子类型都已被case分支覆盖，从而避免了运行时因遗漏某种类型而导致的错误。这种编译期的安全保障，将许多潜在的运行时错误消灭在萌芽状态，使得代码更加健壮。

增强代码的可维护性与表达力

从可维护性的角度看，Sealed Classes使得代码的意图更加清晰。任何阅读代码的开发者都能一目了然地知道一个类有哪些直接的子类型，而无需在整个代码库中搜索所有的继承者。这极大地降低了理解复杂继承树的心智负担，简化了代码的阅读和维护工作。它为领域驱动设计（DDD）提供了更强大的表达能力，能够精确地建模那些具有固定、已知子类型的领域概念（如“支付方式”只能有“信用卡”、“支付宝”、“微信支付”等有限的几种实现）。这种显式的声明使得API的契约更加明确，减少了误用的可能性。

Sealed Classes与模式匹配的强强联合

Sealed Classes价值的最大化体现在与Java后续版本中模式匹配特性的结合上。Java 17中正式引入了针对switch的模式匹配预览特性。当一个switch表达式作用于一个密封类引用时，由于所有可能的子类型在编译时是已知的，编译器可以确保所有情况都被处理。这不仅消除了对default子句的过度依赖（有时甚至不需要default），还使得代码逻辑更加清晰和自信。开发者可以放心地添加新的子类，因为编译器会在所有相关的switch表达式中提醒需要补充新的case分支，从而有效地保障了代码在演进过程中的一致性。

实际应用示例与最佳实践

一个典型的应用场景是建模一个图形计算库。我们可以定义一个密封的`Shape`（形状）类，只允许`Circle`（圆形）、`Rectangle`（矩形）和`Triangle`（三角形）继承它。在计算总面积的方法中，使用switch表达式对`Shape`进行模式匹配，编译器会确保所有三种形状的处理逻辑都已涵盖。最佳实践包括：优先考虑使用sealed hierarchies来明确限制继承关系；在不需要进一步扩展的子类上使用final；谨慎使用non-sealed以在受控范围内重新开放扩展；并充分利用IDE和编译器的 exhaustiveness 检查来编写更安全的代码。