Java 17 密封类（Sealed Classes）概述

密封类是 Java 17 中引入的一项重要特性，它作为一种强大的语言工具，允许类或接口的作者明确控制哪些其他类或接口可以扩展或实现它们。这一特性通过引入 `sealed`、`permits` 等关键字，为域建模和 API 设计提供了更精细的继承控制能力，旨在替代以往通过包级私有构造器等不太直观的方式来实现的受限继承模式。它不仅增强了代码的可读性和可维护性，更能使编译器在模式匹配等场景中进行更全面的穷尽性检查，从而提升程序的健壮性。

密封类的核心语法与设计模式

密封类的声明非常简单直观。核心在于使用 `sealed` 关键字修饰一个类或接口，并通过 `permits` 关键字紧随其后，明确列出允许扩展该密封类或实现该密封接口的子类型。

定义密封基类

以下代码定义了一个名为 `Shape` 的密封抽象类，它只允许 `Circle`、`Rectangle` 和 `Square` 这三个类继承它。

public sealed abstract class Shape    permits Circle, Rectangle, Square {    // ... 公共属性和方法}

定义密封子类

被许可（permitted）的子类必须直接继承密封类。它们自身也必须具有关于继承的明确界定：

public final class Circle extends Shape {    private final double radius;    // ... 构造函数和方法}public non-sealed class Rectangle extends Shape {    private final double length, width;    // ... 构造函数和方法}public sealed class Square extends Shape permits ColoredSquare {    private final double side;    // ... 构造函数和方法}

子类可以是 `final`，阻止进一步的扩展；可以是 `non-sealed`，重新开放继承（但打破了密封性）；也可以是 `sealed`，形成另一层密封层次，如 `Square` 又许可了 `ColoredSquare`。

密封类的设计优势与模式

密封类的设计模式核心在于“受限的层次结构”（Restricted Hierarchy）。它带来的主要优势包括：

精确的域建模

在领域驱动设计（DDD）中，我们常常需要精确表达一个有限集合的子类型。例如，在图形系统中，`Shape` 的类型是已知且固定的。使用密封类可以完美地在类型系统中编码这一业务规则，防止意外或恶意的类扩展，使代码更加忠实于现实世界的领域模型。

增强的编译器检查

与 Java 14 引入的 `instanceof` 模式匹配和 Java 17 的 `switch` 模式匹配结合使用时，密封类的威力巨大。编译器能够知道所有可能的子类型，因此可以对模式匹配进行穷尽性（exhaustiveness）检查。如果缺少对某个许可子类的 case 分支，编译器将报错，从而避免了运行时错误。

double area(Shape shape) {    return switch (shape) {        case Circle c -> Math.PI  c.radius()  c.radius();        case Rectangle r -> r.length()  r.width();        case Square s -> s.side()  s.side();        // 无需default分支，因为所有Shape子类都已覆盖    };}

替代枚举的复杂场景

当每个子类型需要具有不同的状态和行为时，密封类比枚举更强大。枚举适合固定数量的单例值，而密封类适合固定数量但具有不同数据结构和行为的类型层次结构。

实战应用与最佳实践

在实际项目开发中，密封类有多种应用场景。

API 设计中的契约强化

在设计供他人使用的库或框架时，密封接口可以严格定义一组允许的实现。例如，一个用于定义日志级别的密封接口，可以确保用户只能使用预定义的 `INFO`、`WARN`、`ERROR` 等实现，而不能创建不合规的日志级别，保证了API的稳定性和一致性。

状态机建模

在实现状态机（如订单状态：`Created`、`Paid`、`Shipped`、`Delivered`）时，密封类是理想的选择。每个状态可以是一个密封子类，并在其内部定义仅在该状态下允许的操作，编译器能确保所有状态转移都被正确处理。

与记录类（Records）的强强联合

Java 16 引入的记录类（Record）常用于透明地承载数据。将记录类作为密封类的子类是一种极其强大的组合。记录类负责以简洁的方式承载数据，而密封父类则定义了数据的种类，二者结合可以构建出既安全又简洁的数据模型。

public sealed interface Expr    permits ConstantExpr, PlusExpr, TimesExpr, NegExpr {...}public record ConstantExpr(int i) implements Expr {}public record PlusExpr(Expr a, Expr b) implements Expr {}public record TimesExpr(Expr a, Expr b) implements Expr {}public record NegExpr(Expr e) implements Expr {}

这样的代数数据类型（ADT）模型是函数式编程中的常见模式，现在可以在 Java 中优雅地实现。

注意事项与迁移策略

引入密封类时需注意以下几点。首先，`permits` 列表中指定的子类必须与密封类在同一模块中。若未定义模块，则必须在同一包中。其次，选择将子类声明为 `final` 还是 `non-sealed` 需要深思熟虑，`non-sealed` 会打破密封性，应谨慎使用。对于已有代码的迁移，可以逐步将原本用于限制继承的技巧（如私有构造器+工厂方法）重构为密封类，这通常会使代码更加清晰和表达力更强。

总结

Java 17 的密封类是一项提升语言表达力和代码安全性的关键特性。它通过编译时的严格检查，将以往只能在文档或运行时才能表达的约束固化到了类型系统之中。无论是用于精确的域建模、构建更安全的API，还是与模式匹配、记录类等新特性协同工作，密封类都展现出巨大的价值。对于追求更高代码质量和可维护性的 Java 开发者而言，深入理解并应用密封类无疑是迈向现代 Java 开发的重要一步。