理解Sealed Classes的核心概念

Sealed Classes（密封类）是Java 17中引入的一项正式特性，它允许类或接口的作者明确控制哪些其他类或接口可以扩展或实现它们。这为Java的类型系统增添了更强的约束性和表现力，是在final（完全禁止继承）和open（允许无限制继承）之间提供的一个精细控制选项。通过使用sealed、permits和non-sealed等关键字，开发者可以定义一个封闭的类层次结构，编译器能够知晓所有可能的子类型，从而在模式匹配等场景中提供更好的类型检查和代码分析。

场景一：精确建模已知子类的领域模型

在领域驱动设计（DDD）中，我们常常需要精确建模有固定子类型的概念。例如，在一个支付系统中，支付方式（PaymentMethod）的类型是固定的，如信用卡（CreditCard）、 PayPal和银行转账（BankTransfer）。使用Sealed Classes可以完美地强制这种约束，防止不可控的继承破坏领域模型的完整性。

实战指南

首先，我们定义一个sealed接口PaymentMethod，并使用permits关键字明确列出其所有实现类。这些子类必须直接存在于同一模块或包中（在模块化项目中，则需在同一模块或显式导出的模块中）。

```java// 定义密封接口，并许可三种具体的支付方式public sealed interface PaymentMethod permits CreditCard, PayPal, BankTransfer { String getAccountId();}// 信用卡支付方式：定义为final，不允许进一步继承public final class CreditCard implements PaymentMethod { private final String cardNumber; // ... 构造方法和其他逻辑 @Override public String getAccountId() { return this.cardNumber; }}// PayPal支付方式：定义为non-sealed，允许其他类继承它（根据需要）public non-sealed class PayPal implements PaymentMethod { private final String email; // ... 构造方法和其他逻辑 @Override public String getAccountId() { return this.email; }}// 银行转账支付方式：定义为finalpublic final class BankTransfer implements PaymentMethod { private final String accountNumber; // ... 构造方法和其他逻辑 @Override public String getAccountId() { return this.accountNumber; }}```

在这种设计中，如果有人试图创建一个新的BitcoinPayment类并实现PaymentMethod，编译器将会报错，因为它不在permits的列表中。这确保了领域模型的稳定性和可预测性。

场景二：增强switch表达式与模式匹配的类型安全性

Java 17中的模式匹配（Pattern Matching for switch，预览特性）与Sealed Classes结合使用时，能发挥出巨大的威力。由于编译器知晓所有可能的子类，当我们使用switch表达式处理一个密封类时，编译器可以检查是否已经穷尽了所有可能的情况，从而避免运行时错误，并使我们无需编写多余的default子句。

实战指南

假设我们有一个处理支付方法的业务逻辑，我们可以利用switch表达式来处理每一种具体的支付方式，并且得益于Sealed Classes，编译器会确保我们的case覆盖是完整的。

```javapublic class PaymentProcessor { public String processPayment(PaymentMethod method) { // 使用switch表达式进行模式匹配 return switch (method) { // 编译器知道所有可能的PaymentMethod子类，因此会检查穷尽性 case CreditCard cc -> processCreditCard(cc); case PayPal pp -> processPayPal(pp); case BankTransfer bt -> processBankTransfer(bt); // 如果注释掉其中任何一个case，编译器将报错：未穷尽所有可能的值 }; } private String processCreditCard(CreditCard cc) { return Processing credit card: + cc.getAccountId(); } private String processPayPal(PayPal pp) { return Processing PayPal: + pp.getAccountId(); } private String processBankTransfer(BankTransfer bt) { return Processing bank transfer: + bt.getAccountId(); }}```

这种组合极大地提高了代码的健壮性和可维护性。当未来需要添加新的支付方式时，开发者必须首先在permits列表中声明它，然后编译器会立即在所有的switch表达式中提示需要处理这个新的 case，这有效防止了因遗漏而导致的bug。

场景三：构建安全且可扩展的API

在设计供他人使用的库或框架API时，Sealed Classes是一种非常强大的工具。它允许API开发者对外暴露一个基类或接口，但同时严格限制其扩展范围。这防止了客户端代码进行意料之外的实现，从而保证了API内部逻辑的安全性、一致性和可演化性。例如，API可以设计一个密封的返回值类型，确保客户端只能处理已知的、受控的几种响应类型。

实战指南

假设我们设计一个API，其某个方法的返回值可能代表成功（Success）、警告（Warning）或错误（Error）三种状态。我们可以使用Sealed Classes来定义这个返回值类型。

```java// 密封接口，定义API响应的类型public sealed interface ApiResponse permits Success, Warning, Error { String getMessage();}public final class Success implements ApiResponse { private final String message; private final Object data; // ... 构造方法 @Override public String getMessage() { return message; } public Object getData() { return data; }}public final class Warning implements ApiResponse { private final String message; private final String reason; // ... 构造方法 @Override public String getMessage() { return message; } public String getReason() { return reason; }}public final class Error implements ApiResponse { private final String message; private final int errorCode; // ... 构造方法 @Override public String getMessage() { return message; } public int getErrorCode() { return errorCode; }}```

API的使用者在处理返回值时，必须通过模式匹配或instanceof来检查具体的类型（Success, Warning, Error）。API的设计者因此可以确信，客户端代码不会出现奇怪的、未经验证的ApiResponse实现，这简化了内部逻辑并保证了行为的一致性。未来如果需要增加新的响应类型（如Info），只需将其添加到permits列表中并更新相关逻辑，而不会破坏现有的客户端代码，只要它们使用了穷举的switch表达式。