Java Sealed Classes耦合问题：密封接口和子类是否为同一单元

是的，sealed interface与其所有许可的子类应当被视为同一个不可分割的完整单元，而非彼此独立的模块化组件，这是Java密封类特性的设计本身决定的，和常规设计原则里的「高耦合是不良信号」并不冲突。

设计逻辑说明 #

• 常规设计中强调低耦合、类要尽可能少感知其他类细节，前提是你希望组件具备独立替换、支持未知外部扩展的能力。而密封类的核心设计目标刚好相反：它从设计层面就明确限制了这个类型的实现范围，明确告知编译器和后续开发者，这个类型的实现只能是permits列表里指定的几个子类，不允许外部任意扩展，这种刻意的绑定是符合设计预期的，不属于不良耦合。
• Java对密封类有强制语法约束：sealed interface许可的所有子类，必须和该接口属于同一个模块；如果是未命名模块的场景，还要求所有子类和接口处于同一个包。哪怕是你给出的跨包子类实现示例：

import asdf.Car;
import asdf.Truck;

public sealed interface Service permits Car, Truck {

这种跨包的实现也没有突破「同一模块」的边界，本质还是同一个设计单元内部的代码拆分，不属于跨独立模块的依赖。

• 独立模块化组件的核心属性是可独立替换、可独立升级，而sealed interface和它的子类是强绑定的：如果你要新增、删除、修改子类，必须同步修改sealed interface的permits列表；反过来如果sealed interface的permits列表变了，子类的合法性也会受影响，两者根本不可能单独替换，天然就不满足独立模块化组件的要求。

根据Java密封类特性的核心设计者Brian Goetz的相关说明，Java语言规范之所以做这种强绑定约束，就是因为密封类的典型使用场景就是实现代数数据类型（ADT），这类类型层次本身就是语义完整的整体，比如用sealed interface表示树形结构的节点、表示服务的返回结果这类场景下，所有子类本来就是和父接口一起设计、一起发布的，不存在单独扩展或者替换的需求，把它们视为同一个单元完全符合设计直觉。

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