在 Java 中，当一个接口扩展另一个接口时，为什么要在子接口中重新声明一个方法？答案

【问题标题】：In Java when one interface extends another, why would one redeclare a method in a subinterface?在 Java 中，当一个接口扩展另一个接口时，为什么要在子接口中重新声明一个方法？
【发布时间】：2010-10-08 12:22:43
【问题描述】：

我一直在查看来自 J2EE 的 JMS API，并发现了一个奇怪的行为，其中在接口中声明的某些方法（例如，会话中的 createQueue）在子接口（如 QueueSession）中再次声明，并且具有相同的文档。

由于一个子接口“继承”了它所继承的接口的所有方法声明，而且由于JavaDoc工具对子接口的JavaDocs进行整理并创建一个“继承的操作”列表没有问题，我不知道是什么这样就达到了。

唯一想到的是最初调用是在 Session 中，然后在创建特定子类时移动到 QueueSession，尽管那时我希望在上层类的文档中看到一些东西。但这只是猜测。

所以问题是：在子接口中重新声明方法是否有令人信服的理由？

【问题讨论】：

标签： java interface

【解决方案1】：

在为 Sun 工作时偶尔会看到这种情况，我可以告诉你它通常是如何发生的。有人用一些方法定义了一个接口，比如说 Alice；许多开发人员实现了该接口。

一段时间后，他们意识到他们需要一些其他接口，称为 Bob，它具有 Alice 方法的子集，以便允许它作为 另一个的基本接口界面，克拉拉。

如果将 Alice 的方法移到 Bob 中，就会破坏所有实现 Alice 的代码；你必须回去至少重新编译一大堆代码，其中一些你可能不拥有，并且出于政治原因不能破坏。

所以你没有。

【讨论】：

这是有道理的。但是为什么不改变超类中的 JavaDocs 并说“帮我一个忙，永远不要直接调用我，实例化子接口”？
因为那是承认错误？更严重的是，可能是超“类”接口是有时单独使用的；重构没有理由不能简单地删除方法。
“他们意识到他们需要一些其他接口，称之为 Bob，它具有 Alice 的方法的一个子集”如果他们只需要 Alice 的一个子集，为什么他们不能让 Bob 成为一个只有 Alice 的几个方法的单独接口，而不是让 Alice 成为它的超类？
因为有时继承很重要。现在 Bob 对象可以包含在 Alice 的数组中。现在，有时你不需要那个，然后你不应该这样做。但是，如果您确实需要，就必须这样做。
@CharlieMartin - 仍然是一家伟大的公司，拥有许多知识渊博的伟大人物，可惜它走到了尽头。

【解决方案2】：

在 Java 5 中，您可以更改覆盖方法的返回类型，使其更加具体。更常见的是文档不同，因此必须再次声明该方法。

但是，如果方法和文档相同，则不需要它。但是，您会看到大量并非严格需要的代码。有可能它曾经被需要，但有些东西被改变了，所以不再需要它了。很有可能从来不需要它，而是因为开发人员认为需要做某事而实际上并没有很好的基础。

顺便说一句：不同的人对需要什么或方便拥有或更好地明确表达有不同的看法。

【讨论】：

【解决方案3】：

我从来没有看到一个很好的理由。我见过的最好的是：

不用看父母就可以清楚地知道它是什么
它可以更轻松地更改类扩展的内容，而无需弄清楚它应该实现哪些接口

我不喜欢这两个建议。我认为可能的原因是，在编写代码时，接口是在抽象类之前编写的，开发人员没有费心去删除重复的实现。

永远不要低估开发人员的懒惰:-)

除了在类加载时，加载具有重复接口的类可能需要更长的时间。

【讨论】：

【解决方案4】：

我会说不，没有理由这样做。不过，我可以想象在某些代码的演变过程中可能会以几种方式发生这种情况。采用现有接口并从中拉出较小的超级接口的情况并不少见。在这种情况下，我可以想象离开现有的界面，而只是将其更改为从新界面扩展。

【讨论】：

【解决方案5】：

我知道的唯一原因是扩大方法的可见性（即从受保护克隆到公共），但这里似乎并非如此。

【讨论】：

这在界面上是不可能的。方法的可见性由接口本身的可见性定义。并且不允许降低子界面中的可见性。
另外，Cloneable 没有任何方法