Java 新技术:封闭类

发布于 2020-9-10 16:51
浏览
0收藏

封闭类提议进入JDK 15
2020年5月13日,封闭类提案提交审议,目前还没有反对的声音。不出意外的话,该提案会在两个星期内获得批准,并且成为JDK 15的一部分。过一段时间,大概三五个星期的样子,你如果想要先睹为快,可以去下载JDK 15的抢先体验版。

 

由于封闭类已经提交审议,并且目前还没有反对的声音和修改的建议,该提案基本定型,我们可以先睹为快了。

 

我已经有点等不及,快一起来看看这个新技术。

 

什么是封闭类?
简单地说,封闭类和封闭接口限制可以扩展或实现它们的其他类或接口。封闭类和封闭接口使用类修饰符sealed。

 

到Java SE 14为止,java.lang.constant.ConstantDesc的声明还是一个常规的公开接口。它的接口声明看起来像下面的样子:

package java.lang.constant;

public interface ConstantDesc {
    ...
}

这个接口或许会在JDK 15变更为封闭类,到时候,它的接口声明看起来是下面的样子:

package java.lang.constant;

public sealed interface ConstantDesc
    permits String, Integer, Float, Long, Double,
            ClassDesc, MethodTypeDesc, DynamicConstantDesc {
    ...
}

这个封闭接口的声明表明,只有permits关键字后面的类,包括String, Integer等,能够实现这个接口。permits关键字限定了封闭类或者封闭接口的可扩展范围。

 

类修饰符sealed和permits关键字一起,使得封闭类和封闭接口只能在一个限定的、封闭的范围内,获得扩展性。

 

为什么需要封闭类?

可扩展性不是面向对象编程的一个重要指标吗?为什么要限制可扩展性呢?其实,面向对象编程的最佳实践之一,就是要把可扩展性的限制在可以预测和控制的范围内,而不是无限的可扩展性。

 

在极客时间专栏《代码精进之路》里,我们讨论了继承的安全缺陷。其中,主要有两点值得我们格外小心(原文摘录,如涉及版权问题,希望极客时间可以许可我这里少许的引用):

 

一个可扩展的类,子类和父类可能会相互影响,从而导致不可预知的行为。
涉及敏感信息的类,增加可扩展性不一定是个优先选项,要尽量避免父类或者子类的影响。

我们使用了 Java 语言来讨论继承的问题,其实这是一个面向对象机制的普遍的问题,甚至它也不单单是面向对象语言的问题,比如使用 C 语言的设计和实现,也存在类似的问题。

由于继承的安全问题,我们在设计API时,有两个要反省思考的问题:

一个类,有没有真实的可扩展需求,能不能使用 final 修饰符?
一个方法,子类有没有重写的必要性,能不能使用 final 修饰符?

限制住不可预测的可扩展性,是实现安全代码的一个重要目标。

 

目前而言,限制住可扩展性只有两个方法,使用私有类或者final修饰符。显而易见,私有类不是公开接口,只能内部使用。而final修饰符彻底放弃了可扩展性。要么全开放,要么全封闭,可扩展性只能在可能性的两个极端游走。全封闭彻底没有了可扩展性,全开放又面临固有的安全缺陷,这种二选一的状况有时候很让人抓狂,特别是设计公开接口的时候。

 

通过把可扩展性的限制在可以预测和控制的范围内,封闭类打开了全开放和全封闭两端之间的中间地带,为接口设计和实现提供了新的可能性。

 

我一点都不会奇怪,这一项技术很快、很快、很快就会被大面积采用。因为,苦可扩展性久矣!你大概可以猜到,我为什么这么着急地要聊聊封闭类了。

 

怎么使用封闭类?
怎么声明封闭类

封闭类的声明使用sealed类修饰符,然后在所有的extends和implements语句之后,使用permits指定允许扩展该封闭类的子类。 比如:

public sealed class Shape
        permits Circle, Rectangle, Square {
    ...
}

permits关键字指定的许可子类(permitted subclasses),必须和封闭类处于同一模块(module)或者包空间(package)里。如果允许扩展的子类和封闭类在同一个源代码文件里,封闭类可以不使用permits语句,Java编译器将检索源文件,在编译期为封闭类添加上许可的子类。 比如下面的两种Shape封闭类的声明具有一样的运行时效果:

seal class Shape {
   ....
}

private final class Circle extends Shape {
   ...
}

private final class Rectangle extends Shape {
   ...
}

private final class Square extends Shape {
   ....
}
seal class Shape permits Circle, Rectangle, Square {
   ....
}

private final class Circle extends Shape {
   ...
}

private final class Rectangle extends Shape {
   ...
}

private final class Square extends Shape {
   ....
}

 

怎么声明许可类
许可类的声明需要满足下面的三个条件:

在编译期,封闭类和封闭接口必须可以访问它的许可类;
许可类必须是封闭类或者封闭接口的直接扩展类或者直接实现类;
许可类必须声明是否继续保持封闭。
许可类可以声明为终极类(final),从而关闭扩展性;
许可类可以声明为封闭类(sealed),从而延续受限制的扩展性;
许可类可以声明为解封类(non-sealed), 从而支持不受限制的扩展性。

比如下面的例子中,许可类Circle是终极类,Rectangle是封闭类,Square是解封类。

seal class Shape permits Circle, Rectangle, Square {
    ....
}

private final class Circle extends Shape {
    ...
}

private sealed class Rectangle extends Shape
    permits TransparentRectangle, FilledRectangle{
    ...
}

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

需要注意的是,由于许可类必须是封闭类的直接扩展,因此许可类不具备传递性。也就是说,上面的例子中,TransparentRectangle是Rectangle的许可类,但不是Shape的许可类。

 

怎么判断许可类?
我们有时候需要判断一个封闭类声明的变量,是由哪一个子类实现的。由于许可类是子类的一个类型,我们的当然可以使用instanceof 关键字。

Shape flip(Shape shape) {
  if (shape instanceof Circle) {
      return shape;
  } else if (shape instanceof Rectangle) {
      return shape.flip();
  } else if (shape instanceof Square) {
			return shape;
	}
}

不过,由于在编译期,封闭类已经知道了它所有的许可类,许可类的判断可以有更皮实的用法。上面的例子中,如果漏掉某一个if-else语句,编译器都不会报错。当然,也不应该报错。这其实也是一种的类的继承机制带来的常见问题。

 

不受限制的扩展性,使得我们没有办法穷举可能的子类。因此,不论我们怎么努力,我们都没有办法控制可扩展类的安全性和健壮性。封闭类为我们更好地控制子类提供了新的可能性。

 

通过和型式测试(JEP 375,我们以后有时间聊聊这个新技术)技术的结合,编译器可以帮助我们检查穷举所有的许可类。比如,下面的例子中,如果遗漏掉了某一个case语句,编译器就会报错。

Shape flip(Shape shape) {
  return switch (shape) {
      case Circle c  -> c;		// no action needed
      case Rectangle r -> r.flip();
      case Square s  -> s;		// no action needed
  };
}

所以,封闭类在把可扩展性的限制在可以预测和控制的范围内同时,还解决了子类穷举的问题。

 

我们可以学到什么?
最后,对于封闭类,我觉得有两点值得我们特别关注:

通过封闭类可以把可扩展性的限制在可以预测和控制的范围内,这为接口设计和实现提供了新的可能性;
通过和型式测试的结合,许可类可以穷举,这使得我们可以更好地控制代码的安全性和健壮性。

 

来源:InfoQ 

标签
已于2020-9-10 16:51:43修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐