Java语言新特性？封印类，前端开发模式

这离在 switch 中使用类型模式已经不远了。(Java SE 15 还不支持，但很快就会出现。) 到了那个时候，我们可以使用 switch 表达式（case 后面直接是类型）来计算一个形状的面积，如下所示：

float area = switch (shape) {case Circle c -> Math.PI * c.radius() * c.radius();case Rectangle r -> Math.abs((r.upperRight().y() - r.lowerLeft().y())* (r.upperRight().x() - r.lowerLeft().x()));// 不需要提供默认情况！``}

封印类在这里的作用是可以不使用默认子句，因为编译器从 Shape 的声明中已经知道 Circle 和 Rectangle 覆盖了所有形状，因此默认子句不会被执行。(编译器仍然会悄悄地在 switch 表达式中插入一个默认子句，这样做是为了防止在编译和运行这段时间内子类型发生变化，但没有必要让程序员来做这件事情。) 这类似于对枚举进行 switch，因为枚举覆盖了所有已知的常量，所以也不需要使用默认子句。(对于这种情况，忽略默认子句通常会更好，因为使用默认子句好像在提醒我们是不是错过了某种情况）。



Shape 的继承结构给了客户端一个选择：它们可以完全通过抽象接口使用形状，也可以“展开”抽象，并在必要时与更具体的形状发生交互。模式匹配等特性使这种“展开”更易于阅读和编写。



代数数据类型示例



“乘积和”模式非常强大。最好的情况是，子类型列表不发生变化，并预计客户端会直接区分子类型，这样会更容易，也更有用。



限定一组固定的子类型，并鼓励客户端直接使用这些子类型，这是一种紧耦合的形式。在所有条件相同的情况下，我们鼓励使用松耦合的设计，以最大限度地提高灵活性，但这种松耦合也是要付出代价的。在编程语言中同时使用“不透明”和“透明”的抽象可以让我们根据实际情况选择合适的工具。



我们可能已经在 java.util.concurrent.Future API 中使用了一系列乘积和 (如果当时这是一种选择的话)。Future 表示可以与其发起者并发执行的计算，Future 所代表的计算可能还没有开始、已经开始但还没有完成、已经成功完成（或已经完成但出现异常）、已经超时或被中断取消。Future 的 get() 方法反映了所有这些可能性：

interface Future {…V get(long timeout, TimeUnit unit)throws InterruptedException, ExecutionException, TimeoutException;``}

如果计算尚未完成，get() 会一直阻塞，直到完成。如果是成功的，则返回计算结果。如果抛出异常，异常将被封装在 ExecutionException 中。如果计算超时或被中断，则会抛出另一种异常。这个 API 非常精确，但使用起来有些痛苦，因为它有多个控制路径，不管是普通路径 (get() 返回一个值) 还是失败路径，都必须在 catch 块中处理：

try {V v = future.get();// 处理一般的完成情况}catch (TimeoutException e) {// 处理超时}catch (InterruptedException e) {// 处理取消}catch (ExecutionException e) {Throwable cause = e.getCause();// 处理失败``}

如果在 Java 5 引入 Future 时，我们已经有封印类、记录类和模式匹配，那么我们可能会这样定义返回类型：

sealed interface AsyncReturn {record Success(V result) implements AsyncReturn { }record Failure(Throwable cause) implements AsyncReturn { }record Timeout() implements AsyncReturn { }record Interrupted() implements AsyncReturn { }}…interface Future<V> {` `AsyncReturn<V> get();}

在这里，异步结果可以是成功 (包含返回值)、失败 (包含异常)、超时或取消。这是对可能出现的结果更为统一的描述，而不是用返回值描述其中的一些结果，再用异常描述另一些结果。客户端仍然需要处理所有的情况——无法回避任务可能会失败的事实——但我们可以统一地 (并更紧凑地) 处理这些情况（见脚注）：

AsyncResult r = future.get();switch (r) {` `case Success(var result): ...` `case Failure(Throwable cause): ...` `case Timeout(), Interrupted(): ...}

乘积和是一种广义的枚举



我们可以把乘积和看成是一种广义的枚举。枚举声明了一种类型，包含一组完整的常量实例：

enum Planet { MERCURY, VENUS, EARTH, … }

我们可以将数据与每个常数关联起来，例如行星的质量和半径：

enum Planet {MERCURY (3.303e+23, 2.4397e6),VENUS (4.869e+24, 6.0518e6),EARTH (5.976e+24, 6.37814e6),…``}

封印类枚举的不是固定的实例列表，而是固定的实例类型列表。例如，这个封印接口列出了各种天体，以及与各种天体相关的数据：

sealed interface Celestial {record Planet(String name, double mass, double radius)implements Celestial {}record Star(String name, double mass, double temperature)implements Celestial {}record Comet(String name, double period, LocalDateTime lastSeen)implements Celestial {}``}

正如我们可以对枚举常量进行 switch，我们也可以对各种天体进行 switch：

switch (celestial) {case Planet(String name, double mass, double radius): …case Star(String name, double mass, double temp): …case Comet(String name, double period, LocalDateTime lastSeen): …``}

这种模式的例子随处可见：UI 系统中的事件、服务系统中的返回代码、协议中的消息，等等。



更安全的继承结构



到目前为止，我们已经讨论了在什么情况下封印类对领域建模是有帮助的。封印类还有另一个完全不同的应用：更安全的继承结构。



在 Java 里，我们通过将类标记为 final 来表示“这个类不能被继承”。final 在语言中的存在说明了一个关于类的基本事实：有时候类被设计为可扩展的，有时候则不是，我们希望同时支持这两种模式。实际上，《 Effective Java》建议我们“为扩展而设计，否则就禁止扩展”。这是一个很好的建议，如果编程语言在这方面为我们提供更多的帮助，我们可能会更容易接受这个建议。



可惜的是，编程语言在两方面未能帮到我们：默认的类是可扩展的，而 final 机制实际上非常弱，因为它迫使程序员在约束扩展和使用多态性之间做出选择。以 String 为例，字符串是不可变的，因此 String 不能被继承，这对平台的安全性来说至关重要——但对于实现来说，拥有多个子类型会更为方便。解决这个问题的成本是巨大的。紧凑字符串对仅由 Latin-1 字符组成的字符串进行了特殊处理，从而显著降低了占用空间，并提升了性能，但如果 String 是一个封印类而不是 final 的类，这样做会更容易、成本更低。



有一种方法可以模拟封印类（不是接口），即使用包内可见的构造函数，并将所有实现放在同一个包中。虽然这样做是可以的，但令人感到不是很舒服，因为你要公开一个抽象类，但又不希望被扩展。程序库作者更喜欢使用接口来公开不透明的抽象，但抽象类是用来为实现提供辅助的，并不是建模工具（参见《Effective Java》的“Prefer interfaces to abstract classes”）。



有了封印接口，程序库作者不需要再纠结是使用多态性、是允许不受控制的扩展还是将抽象公开为接口——他们可以同时拥有这三种技术。作者可能会选择让实现类可访问，但更有可能让实现类保持封装性。



封印类允许程序库作者将可访问性与可扩展性解耦。这种灵活性很好，但我们应该在什么时候使用呢？当然，我们不希望将 List 变成封印接口，因为对于用户来说，创建新类型的 List 是完全合理和可取的。封印既有成本 (用户不能创建新的实现) 也有好处 (可以全局控制实现)，我们应该在好处高过成本的时候使用封印。