Java类实现多接口时，为何要同时实现已被其他接口继承的父接口？

你观察到的这种写法，在成熟类库设计中非常常见，典型例子就是JDK中的AbstractInterruptibleChannel类定义：

public abstract class AbstractInterruptibleChannel
    implements Channel, InterruptibleChannel

按照Java的接口继承规则，InterruptibleChannel本身已经继承了Channel接口：

public interface InterruptibleChannel
    extends Channel

单从语法上看，在implements列表里额外写出Channel好像是重复冗余的代码，但这种写法不是手滑导致的失误，而是经过长期考量的设计选择，背后的原因主要有这几个：

• 降低读代码的认知成本，提升可读性
  类声明的implements列表是开发者判断一个类核心定位的第一参考信息。如果只写implements InterruptibleChannel，开发者需要点进InterruptibleChannel的源码，顺着继承链确认它实现了Channel，才能知道这个类属于通道体系。而直接把Channel列在实现列表里，相当于把这个类的核心身份标签直接打在类声明的最显眼位置，不需要额外跳转就能建立完整的认知。对于被海量开发者浏览的JDK类库来说，这种减少跳转、直给信息的写法，长期来看能节省非常多的沟通和阅读成本。
• 适配文档生成的友好性
  Java自带的javadoc工具在生成类文档时，会优先把类显式声明实现的接口放在文档的核心关联区块。如果只靠子接口隐式传递实现关系，Channel作为根接口，需要顺着多层继承链才能和AbstractInterruptibleChannel建立文档关联，查阅文档的开发者无法第一时间意识到这个类属于通道体系的实现。显式声明的写法，能让文档的结构更清晰，核心接口的关联关系更突出。
• 规避长期演进的潜在兼容风险
  从语法规则上，只要类实现了子接口InterruptibleChannel，就自动满足了父接口Channel的契约，但这种隐式的绑定关系存在长期变动的可能性。如果未来接口体系做重构（比如调整InterruptibleChannel的继承关系，移除对Channel的继承），没有显式声明实现Channel的类，会直接丢失作为Channel实现的身份匹配能力。而显式在implements列表中写出Channel的类，不会受到子接口继承关系变动的影响，始终保持和Channel接口的绑定。虽然这种极端变动在JDK的稳定API中极少发生，但对于类库的长期可维护性来说，这种显式绑定是非常稳妥的设计选择。
• 统一团队代码规范的要求
  很多成熟开发团队的代码规范会要求：只要类属于某一个核心接口的实现体系，不管是直接实现、还是通过子接口隐式获得了实现资格，都必须在类声明中显式写出对应的根接口。这种统一的要求能避免出现“有的类显式写了根接口、有的类靠隐式传递实现”的风格不一致问题，减少团队协作中的认知偏差。

补充说明：这种重复声明接口的写法在Java语法层面是完全合法的，不会带来任何编译期或者运行时的额外开销。JVM在加载类时，会自动对接口实现列表中的重复引用做去重处理，既不会生成冗余的方法表，也不会影响类的加载性能，Java语言规范也明确允许这种写法存在。

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