Java 17 密封类（Sealed Classes）深度解析

密封类是 Java 17 引入的核心特性，旨在通过精细化控制继承关系来增强代码安全性与可维护性。其核心思想是：显式声明允许继承的子类，而非默认的开放继承模式。

一、密封类解决的问题

传统继承体系存在两大痛点：

1. 不可控的扩展性
   任意类均可继承公开父类，导致不可预见的子类破坏设计意图
2. 类型安全检查缺失
   在模式匹配（如 switch）时无法穷举所有子类型

密封类通过编译器级别的约束，使继承体系成为封闭可控的代数数据类型。

二、核心语法结构

1. 定义密封父类

public sealed class Shape 
    permits Circle, Square, Rectangle { // 显式声明允许的子类
    // 类主体
}

2. 子类约束（三选一）

• final 子类（禁止进一步继承）

  public final class Circle extends Shape { ... }
  

• sealed 子类（创建次级密封体系）

  public sealed class Rectangle extends Shape 
      permits FilledRectangle, TexturedRectangle { ... }
  

• non-sealed 子类（开放部分继承分支）

  public non-sealed class Square extends Shape { ... }
  

三、关键设计原则

1. 编译期契约检查

   • 所有 permits 子类必须直接继承该密封类
   • 子类需声明为 final/sealed/non-sealed 三者之一

2. 模块化可见性

   • 子类需与密封类位于同一模块（或未命名模块的同一包）
   • 避免跨模块的不可控继承

3. 类型系统协同

   double area(Shape s) = switch(s) {
       case Circle c -> c.radius() * c.radius() * Math.PI;
       case Square sq -> sq.side() * sq.side();
       // 编译器确保所有permits类型被覆盖
   };
   

四、典型应用场景

1. 领域模型安全

   public sealed interface PaymentMethod 
       permits CreditCard, PayPal, BankTransfer { ... }
   

   确保支付方式不会被意外扩展

2. 状态机实现

   sealed interface OrderState 
       permits Created, Paid, Shipped, Canceled { ... }
   

   约束状态流转路径

3. 表达式树处理

   sealed abstract class Expr
       permits ConstantExpr, PlusExpr, MinusExpr { ... }
   

   实现类型安全的AST遍历

五、与其它语言的对比

六、最佳实践建议

1. 最小化 non-sealed 使用
   仅在确需部分开放继承时使用，避免破坏封装性
2. 结合 record 类型
   使用不可变数据载体强化类型安全：

   public sealed interface Result<T> 
       permits Success<T>, Failure<T> {}
   
   public record Success<T>(T data) implements Result<T> {}
   public record Failure<T>(String error) implements Result<T> {}
   

3. 模块化隔离
   将密封类体系置于独立模块，强化访问控制

演进价值：密封类是 Java 向代数数据类型演进的关键步骤，为未来模式匹配、值类型等特性奠定类型系统基础。通过编译器强制约束，使「设计意图」转化为「可执行的代码契约」，大幅提升复杂系统的可维护性。