java - 用非密封类扩展密封类有什么意义？

Question

我真的不明白为什么会有 non-sealed JEP 360/Java 15 中的关键字。
对我来说，密封类的扩展应该只是 final 或密封类本身。
提供“非密封”关键字将邀请开发人员进行黑客攻击。
为什么我们允许将密封类扩展到非密封类？

Answer 1

因为在现实世界的 API 中，有时我们希望在限制其他扩展点的同时支持特定的扩展点。 Shape然而，例子并不是特别令人回味，这就是为什么允许它看起来很奇怪的原因。
密封类是关于更好地控制谁可以扩展给定的可扩展类型。您可能想要这样做有几个原因，“确保没有人扩展层次结构”只是其中之一。
在很多情况下，一个 API 有几个“内置”抽象，然后是一个“逃生舱”抽象；这允许 API 作者将潜在的扩展者引导到为扩展而设计的逃生舱口。
例如，假设您有一个使用 Command 的系统。模式，有几个你想要控制实现的内置命令，还有一个 UserPluginCommand对于扩展:

sealed interface Command
    permits LoginCommand, LogoutCommand, ShowProfileCommand, UserPluginCommand { ... }

// final implementations of built-in commands

non-sealed abstract class UserPluginCommand extends Command {
    // plugin-specific API
}

这样的层次结构完成了两件事:

所有扩展都通过 UserPluginCommand ，可以为扩展进行防御性设计，并提供适合用户扩展的API，但我们仍然可以在设计中使用基于接口(interface)的多态性，因为完全不受控制的子类型不会出现；

系统仍然可以依赖以下事实，即四种允许的类型涵盖了 Command 的所有实现。所以内部代码可以使用模式匹配并对其详尽无遗充满信心:

switch (command) {
    case LoginCommand(...): ... handle login ...;
    case LogoutCommand(...): ... handle logout ...;
    case ShowProfileCommand(...): ... handle query ...;
    case UserPluginCommand uc: 
        // interact with plugin API
    // no default needed, this switch is exhaustive

UserPluginCommand 可能有无数个子类型，但系统仍然可以自信地推断出它可以用这四种情况覆盖海滨。 java.lang.constant 将在 JDK 中利用这一点的 API 示例。 ，其中有两种为扩展而设计的子类型——动​​态常量和动态调用点。