定义未包含permits子句的sealed类是否为Java最佳实践？

Sealed类用于限制可继承它的类，通常通过permits子句指定允许的子类。如果不写permits子句，同一编译单元内的任意类都能隐式继承它，存在意外继承的风险。针对你的问题，具体建议如下：

1. 是否应始终包含permits子句？ #

通常建议明确添加permits子句，这能直接体现代码的设计意图，让其他开发者一眼就能知道哪些类被允许继承该密封类，避免后续维护时在同一文件中误加不符合设计预期的子类。尤其是项目规模较大、多人协作时，明确的permits子句能减少沟通成本，降低意外继承的概率。

但这不是强制要求，并非所有场景都必须写。

2. 适合省略permits子句的场景 #

存在合理的省略场景，最典型的是密封类与所有允许的子类都在同一个编译单元（单个.java文件）内，且子类数量少、结构简单。比如定义小型的代数数据类型：

// 省略permits的写法
sealed interface Shape {}
final class Circle implements Shape {}
final class Rectangle implements Shape {}

这种情况下，所有子类都在同一文件里，结构清晰直观，省略permits子句不会造成歧义，还能让代码更简洁，减少冗余。

总结：优先明确写permits子句来管控继承范围；只有当密封类和子类高度内聚在同一文件、结构简单时，才考虑省略permits。

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