Java 17 Sealed Classes业务场景及使用困惑咨询

一、何时需要限制仅特定类继承某个类？ #

业务里这类场景其实很常见，举几个真实例子：

• 领域模型的有限状态/类型：比如电商系统的订单状态，只有待支付、已支付、已取消、已完成这几种固定类型，不会随意新增。把OrderStatus做成密封类，只允许这几个子类继承，能确保所有状态都在可控范围内，避免未知状态引发的逻辑错误。
• 表达式语法树：写简单表达式解析器时，表达式只能是加法、减法、常量、变量这几类，密封类可以保证后续扩展时只有指定子类能加入，不会出现乱七八糟的子类破坏语法树逻辑。
• 权限角色体系：系统角色仅包含管理员、普通用户、访客，密封类能限制只有这三个子类实现角色逻辑，防止有人自定义角色绕过权限校验。

二、自有项目里，为啥不直接用非final/非密封类，要折腾密封类？ #

看似只是多了个允许列表，但密封类的价值远大于那点可忽略的开销：

• 编译期强校验：如果有人想继承密封类却没加入允许列表，编译直接报错，不用等到运行时才暴露问题。非密封类的话，除非手动做检查，否则很容易出现意外子类。
• 清晰的代码边界：看代码时一眼就能知道这个类有哪些子类，不用全局搜索继承关系，维护起来更高效。尤其是项目变大、新人接手时，能快速理解类的设计意图。
• 配合模式匹配增强：Java 17+的switch模式匹配对密封类支持更完善，处理密封类子类时，编译器会检查是否覆盖所有情况，不用写默认分支兜底，减少逻辑遗漏。比如：

sealed abstract class Shape permits Circle, Square, Triangle {}
final class Circle extends Shape {}
final class Square extends Shape {}
final class Triangle extends Shape {}

// 编译期自动检查是否覆盖所有Shape子类
double calculateArea(Shape shape) {
    return switch (shape) {
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Square s -> s.side() * s.side();
        case Triangle t -> t.base() * t.height() / 2;
    };
}

要是用非密封类，编译器没法做这个检查，很容易漏掉某个子类的处理。

三、对外提供库时，怎么预先确定允许继承的类？ #

对外库用密封类，核心是明确你提供的扩展点边界：

• 内置固定扩展：比如做日志库时，日志输出方式只有ConsoleLogger、FileLogger、DatabaseLogger这几种官方实现，把Logger做成密封类，只允许这三个子类继承，用户无法自定义Logger，避免破坏库的日志格式、性能控制等逻辑。
• 预留可控扩展接口：如果需要让用户扩展但又想限制范围，可以结合密封类和接口。比如ORM框架中，只允许用户继承BaseEntity的特定子类（如JpaEntity、MybatisEntity），这些子类属于密封类的允许列表，同时提供接口让用户在子类中实现自定义逻辑，既控制了继承范围，又给了用户扩展空间。
• 配合模块系统强化控制：用Java模块系统（Module）时，把密封类和允许子类放在同一个模块里，对外只暴露密封类的API，不暴露子类实现细节，用户即使想继承也访问不到子类代码，进一步强化控制。

内容的提问来源于stack exchange，提问作者bakarJc