Java 17 密封类概述

Java 17 作为一款长期支持（LTS）版本，引入了多项重要特性以增强语言表达能力和安全性，其中密封类（Sealed Classes）的最终定型尤为引人注目。密封类通过提供一种受限制的继承模型，允许类或接口的作者明确声明哪些其他类或接口可以扩展或实现它。这一特性旨在从根本上提升代码的安全性与可维护性，通过限制任意子类化来强化对领域模型的精确建模。

密封类如何提升代码安全性

限制不受控制的扩展

在密封类出现之前，一个被设计为基类的类，如果不被声明为 final，就意味着它对所有其他类开放，可以被任意子类化。这种开放性可能导致不可预见的子类出现，这些子类可能破坏父类所设定的不变量或规约。例如，在处理表示形状的类层次结构时，如果 Shape 类是非密封的，任何代码都可以创建一个新的、可能行为异常的 Shape 子类，这在与 instanceof 检查或模式匹配结合使用时，会引入潜在的错误和安全漏洞。

强化领域建模与编译时检查

密封类将这种开放继承转变为封闭、可控的继承。开发者可以在定义父类时，使用 permits

密封类如何增强代码可维护性

提供清晰的领域模型文档

密封类本身作为代码的一部分，充当了其自身层次结构的权威文档。通过查看基类的声明，开发者可以一目了然地知道整个类体系中有哪些具体的子类型。这种显式声明消除了不确定性，使得新加入项目的开发者能够快速、准确地理解领域模型的边界和组成，降低了代码的理解和维护成本。

赋能 exhaustive 模式匹配

密封类与 Java 中不断发展的模式匹配特性（如 switch 表达式和语句的模式匹配）结合使用时，其价值更加凸显。编译器能够识别出 switch 表达式是否已经覆盖了密封父类所有许可的子类型。如果覆盖完全，编译器则不会要求提供 default 子句；如果存在遗漏，编译器将发出错误警告。这一机制不仅减少了编写冗余 default 子句的需要，更重要的是，当未来需要扩展密封类体系（例如新增一个许可的子类）时，编译器会立即在所有相关的 switch 表达式处报错，强制开发者去处理这个新情况，从而有效防止了因遗漏而导致的运行时错误，极大地提升了代码在演化过程中的可维护性。

Java 17 中密封类的实践应用

语法与示例

在 Java 17 中，定义密封类需要两个关键步骤。首先，在父类声明中使用 sealed 修饰符，并通过 permits 子句列出允许的子类。其次，每个被许可的子类必须直接继承该密封类，并使用 final, sealed 或 non-sealed 修饰符来声明其自身的可扩展性。

例如，定义一个表示数学表达式的密封接口及其实现：

public sealed interface Expr    permits ConstantExpr, PlusExpr, TimesExpr, NegExpr { ... }public final class ConstantExpr implements Expr { ... }public final class PlusExpr implements Expr { ... }public final class TimesExpr implements Expr { ... }public final class NegExpr implements Expr { ... }

此例中，Expr 是一个密封接口，只允许四个已知的实现类。所有这些实现类都被声明为 final，意味着这个层次结构是完全封闭的。

迁移与兼容性考虑

对于已有的代码库，引入密封类是一项非破坏性变更。可以将一个现有的非密封类改为密封类，只要在 permits 子句中列出所有现有的合法子类即可。这个过程不会影响现有代码的功能，但能立即阻止未来创建未经授权的子类，为代码库的长期健康提供了保障。

结论

综上所述，Java 17 的密封类特性通过引入一种声明性的、编译时强制的继承控制机制，显著提升了代码的安全性与可维护性。它将不受限制的继承转变为精心设计的领域模型约束，减少了因不可控扩展而导致错误的风险，同时通过与模式匹配的协同工作，确保了代码在演化过程中的完整性和正确性。对于致力于构建健壮、清晰且易于维护的面向对象系统的开发者而言，密封类是一个不可或缺的强大工具。