你好，我是范学雷。今天，我们聊一聊Java的封闭类。
封闭类这个特性，首先在JDK 15中以预览版的形式发布。在JDK 16中，改进的封闭类再次以预览版的形式发布。最后，封闭类在JDK 17正式发布。
那么，什么是封闭类呢？封闭类的英文，使用的词汇是"sealed classes"。从名字我们就可以感受到，封闭类首先是Java的类，然后它还是封闭的。
Java的类，我们都知道什么意思。那么，“封闭”又是什么意思呢？字面的意思，就是把一些东西封存起来，里面的东西出不去，外面的东西也进不来，所以可查可数。
“封闭”、“可查可数”，这些词汇字面看起来好像很通俗，但是实际上并不容易理解。我们还是通过案例和代码，一步一步地来了解封闭类吧。
在面向对象的编程语言中，研究表示形状的类，是一个常用的教学案例。今天的评审案例，我们也从形状这个类开始，来研究一下怎么判断一个形状是不是正方形吧。
下面的这段代码，就是一个简单的、抽象的形状类的定义。这个抽象类的名字是Shape。它有一个抽象方法area()，用来计算形状的面积。它还有一个公开的属性id，用来标识这个形状的对象。
package co.ivi.jus.sealed.former;public abstract class Shape {public final String id;public Shape(String id) {this.id = id;}public abstract double area();}
我们都知道，正方形是一个形状。正方形可以作为形状这个类的一个扩展类。它的代码可以是下面的样子。
package co.ivi.jus.sealed.former;public class Square extends Shape {public final double side;public Square(String id, double side) {super(id);this.side = side;}@Overridepublic double area() {return side * side;}}
那么，到底怎么判断一个形状是不是正方形呢？这个问题的答案，表面上看起来很简单，只要判断这个形状的对象是不是一个正方形的实例就可以了。这个判断的例子，看起来可以是下面的样子。
static boolean isSquare(Shape shape) {return (shape instanceof Square);}
你可以思考一下，这样是不是真的能判断一个形状是正方形？花几秒钟想想你的答案，我们接下来再继续分析。
其实，上面的这个例子，判断的只是“一个形状的对象是不是一个正方形的实例”。但实际上，一个形状的对象即使不是一个正方形的类，它也有可能是一个正方形。什么意思呢？比如说有一个对象，表示它的类是长方形或者菱形的类。如果这个对象的每一个边的长度都是一样的，其实它就是一个正方形，但是表示它的类是长方形或者菱形的类，而不是正方形类。所以，上面的这段代码还是有缺陷的，并不总是能够正确判断一个形状是不是正方形。
详细地，我们来看下一段代码，你就对这个缺陷有一个更直观的了解了。我们都知道，长方形也是一个形状，它也可以作为形状这个类的一个扩展类。下面的这段代码，定义的就是一个长方形。这个类的名字是Rectangle，它是Shape的扩展类。
package co.ivi.jus.sealed.former;public class Rectangle extends Shape {public final double length;public final double width;public Rectangle(String id, double length, double width) {super(id);this.length = length;this.width = width;}@Overridepublic double area() {return length * width;}}
代码读到这里，对于“怎么判断一个形状是不是正方形”这个问题，我觉得你可能已经有了一个更好的思路。没错，正方形是一个特殊的长方形。如果一个长方形的长和宽是相等的，那么它也是一个正方形。上面的那段“判断一个形状是不是正方形”的代码，就没有考虑到长方形的特例，所以它是有缺陷的实现。
知道了长方形这个类，我们就能改进我们的判断了。改进的代码，要把长方形考虑进去。它看起来可以是下面的样子。
public static boolean isSquare(Shape shape) {if (shape instanceof Rectangle rect) {return (rect.length == rect.width);}return (shape instanceof Square);}
写完上面的代码，似乎就可以长舒一口气：哎，这难缠的正方形，我们终于搞定了。
但其实，这个问题我们还没有搞定。因为正方形也是一个特殊的菱形，如果一个对象是一个菱形类的实例，上面的代码就有缺陷。更令人窘迫的是，正方形还是一个特殊的梯形，还是一个特殊的多边形。随着我们学习一步一步的深入，我们知道还有很多形状的特殊形式是正方形，而且我们并不知道我们知识范围外的那些形状，当然更不能提穷举它们了。
这，实在有点让人抓狂！
问题出在哪里呢？无限制的扩展性，是问题的根源。正如现实世界里，我们没有办法穷举到底有多少形状的特殊形式是正方形；在计算机的世界里，我们也没有办法穷举到底有多少形状的对象可以是正方形。如果我们解决不了形状类的穷举问题，我们就不太容易使用代码来判断一个形状是不是正方形。
而解决问题的办法，就是限制可扩展类的扩展性。
你可能要问，可扩展性不是面向对象编程的一个重要指标吗？为什么要限制可扩展性呢？其实，面向对象编程的最佳实践之一，就是要把可扩展性限制在可以预测和控制的范围内，而不是无限的可扩展性。
除了上面穷举的问题之外，在极客时间专栏《代码精进之路》里，我们还讨论了继承的安全缺陷。其中，主要有两点值得我们格外小心：
一个可扩展的类，子类和父类可能会相互影响，从而导致不可预知的行为。
涉及敏感信息的类，增加可扩展性不一定是个优先选项，要尽量避免父类或者子类的影响。
虽然我们使用了 Java 语言来讨论继承的问题，但其实这些是面向对象机制的普遍问题，甚至它们也不单单是面向对象语言的问题，比如使用 C 语言的设计和实现，也存在类似的问题。
由于继承的安全问题，我们在设计 API 时，有两个要反省思考的点：
一个类，有没有真实的可扩展需求，能不能使用 final 修饰符？
一个方法，子类有没有重写的必要性，能不能使用 final 修饰符？
限制住不可预测的可扩展性，是实现安全代码、健壮代码的一个重要目标。
JDK 17之前的Java语言，限制住可扩展性只有两个方法，使用私有类或者 final 修饰符。显而易见，私有类不是公开接口，只能内部使用；而 final 修饰符彻底放弃了可扩展性。要么全开放，要么全封闭，可扩展性只能在可能性的两个极端游走。全封闭彻底没有了可扩展性，全开放又面临固有的安全缺陷，这种二选一的状况有时候很让人抓狂，特别是设计公开接口的时候。
JDK 17之后，有了第三种方法。这个办法，就是使用Java的sealed关键字。使用类修饰符sealed修饰的类是封闭类；使用类修饰符sealed修饰的接口是封闭接口。封闭类和封闭接口限制可以扩展或实现它们的其他类或接口。
通过把可扩展性的限制放在可以预测和控制的范围内，封闭类和封闭接口打开了全开放和全封闭两个极端之间的中间地带，为接口设计和实现提供了新的可能性。
那么，怎么使用封闭类呢？封闭类这个概念，涉及到两种类型的类。第一种是被扩展的父类，第二种是扩展而来的子类。通常地，我们把第一种称为封闭类，第二种称为许可类。
封闭类的声明使用 sealed 类修饰符，然后在所有的 extends 和 implements 语句之后，使用 permits 指定允许扩展该封闭类的子类。 比如，使用 sealed 类修饰符，我们可以把形状这个类声明为封闭类。下面的这个例子中，Shape是一个封闭类，可以扩展它的子类只有两个，分别为Circle和Square。也就是说，这里定义的形状这个类，只允许有圆形和正方形两个子类。
package co.ivi.jus.sealed.modern;public abstract sealed class Shape permits Circle, Square {public final String id;public Shape(String id) {this.id = id;}public abstract double area();}
由 permits 关键字指定的许可子类（permitted subclasses），必须和封闭类处于同一模块（module）或者包空间（package）里。如果封闭类和许可类是在同一个模块里，那么它们可以处于不同的包空间里，就像下面的例子。
package co.ivi.jus.sealed.modern;public abstract sealed class Shapepermits co.ivi.jus.ploar.Circle,co.ivi.jus.quad.Square {public final String id;public Shape(String id) {this.id = id;}public abstract double area();}
如果允许扩展的子类和封闭类在同一个源代码文件里，封闭类可以不使用 permits 语句，Java 编译器将检索源文件，在编译期为封闭类添加上许可的子类。比如下面的两种 Shape 封闭类的声明，一个封闭类使用了 permits 语句，另外一个封闭类没有使用 permits 语句。但是，这两个声明具有完全一样的运行时效果。
package co.ivi.jus.sealed.improved;public abstract sealed class Shape {public final String id;public Shape(String id) {this.id = id;}public abstract double area();public static final class Circle extends Shape {// snipped}public static final class Square extends Shape {// snipped}}
package co.ivi.jus.sealed.improved;public abstract sealed class Shapepermits Shape.Circle, Shape.Square {public final String id;public Shape(String id) {this.id = id;}public abstract double area();public static final class Circle extends Shape {// snipped}public static final class Square extends Shape {// snipped}}
不过，如果你读过《代码精进之路》，你就会倾向于总是使用permits 语句。因为这样的话，代码的阅读者不需要去翻找上下文，也能一目了然地知道这个封闭类支持哪些许可类。这会给代码的阅读者带来很多的便利，包括节省时间以及少犯错误。
许可类的声明需要满足下面的三个条件：
比如在下面的例子中，许可类 Circle 是一个解封类；许可类 Square 是一个封闭类；许可类 ColoredSquare 是一个终极类；而 ColoredCircle 既不是封闭类，也不是许可类。
package co.ivi.jus.sealed.propagate;public abstract sealed class Shape {public final String id;public Shape(String id) {this.id = id;}public abstract double area();public static non-sealed class Circle extends Shape {// snipped}public static sealed class Square extends Shape {// snipped}public static final class ColoredSquare extends Square {// snipped}public static class ColoredCircle extends Circle {// snipped}}
需要注意的是，**由于许可类必须是封闭类的直接扩展，因此许可类不具备传递性。**也就是说，上面的例子中，ColoredSquare 是 Square 的许可类，但不是 Shape 的许可类。
到这里，我们再回头看看前面的案例，怎么判断一个形状是不是正方形呢？封闭类能帮助我们解决这个问题吗？如果使用了封闭类，这个问题的答案也就呼之欲出了。
首先，我们要把形状这个类定义为封闭类。这样，所有形状的子类就可以穷举了。然后，我们寻找可以用来表示正方形的许可类。找到这些许可类后，只要我们能够判断这个形状的对象是不是一个正方形，问题就解决了。
比如下面的代码，形状被定义为封闭类Shape。而且，Shape这个封闭类只有两个终极的许可类。一个许可类是表示圆形的Circle，一个许可类是表示正方形的Square。
package co.ivi.jus.sealed.improved;public abstract sealed class Shapepermits Shape.Circle, Shape.Square {public final String id;public Shape(String id) {this.id = id;}public abstract double area();public static final class Circle extends Shape {// snipped}public static final class Square extends Shape {// snipped}}
由于Shape是个封闭类，在这段代码的许可范围内，一个形状Shape的对象要么是一个圆形Circle的实例，要么是一个正方形Square的实例，没有其他的可能性。
这样的话，判断一个形状是不是正方形这个问题就变得比较简单了。只要能够判断出来一个形状的对象是不是一个正方形的实例，这个问题就算是解决了。
static boolean isSquare(Shape shape) {return (shape instanceof Square);}
这样的逻辑在案例分析那一小节的场景中并不成立，为什么现在就成立了呢？根本的原因，在案例分析那一小节的场景中，Shape类是一个不受限制的类，我们没有办法知道它所有的扩展类，因此我们也就没有办法穷尽正方形的所有可能性。而在使用封闭类的场景下，Shape类的所有扩展类，我们都是已知的，所以我们就有办法检查每一个扩展类的规范，从而对这个问题做出正确的判断。
好，到这里，我来做个小结。从前面的讨论中，我们了解到，可扩展性的限定方法有四个：
在我们日常的接口设计和编码实践中，使用这四个限定方法的优先级应该是由高到低的。最优先使用私有类，尽量不要使用不受限制的扩展性。
如果要丰富你的代码评审清单，有了封闭类后，你可以加入下面这一条：
一个类，如果有真实的可扩展需求，能不能枚举，可不可以使用 sealed 修饰符？
另外，通过今天的讨论，我拎出几个技术要点，这些都可能在你们面试中出现哦，通过学习，你应该能够：
如果你的代码里使用了封闭类，无论是面试的时候还是工作的时候，一定能够给人深刻的印象。因为，这意味着你已经了解了可扩展性的危害，并且有办法降低这种危害的影响，有能力编写出更健壮的代码。
在案例回顾这一小节里，我们使用了封闭类来解决“怎么判断一个形状是不是正方形”这个问题。我们假设案例回顾这一小节的代码是版本1.0。现在我们假设，在版本2.0里，需要增加另一个许可类，用来支持长方形（Rectangle）。那么：
欢迎你在留言区留言、讨论，分享你的阅读体验以及对这些问题的思考。
注：本文使用的完整的代码可以从GitHub下载，你可以通过修改GitHub上review template代码，完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见，请提交一个 GitHub的拉取请求（Pull Request），并把拉取请求的地址贴到留言里。这一小节的拉取请求代码，请在封闭类专用的代码评审目录下，建一个以你的名字命名的子目录，代码放到你专有的子目录里。比如，我的代码，就放在sealed/review/xuelei的目录下面。