我一直在从J2EE查看JMS API，并发现了一种奇怪的行为，其中在接口中声明的某些方法（例如，Session中的createQueue）在子接口（例如QueueSession）中再次声明，并且具有相同的文档。
由于子接口“继承”它继承的接口的所有方法声明，并且由于JavaDoc工具在排序子接口的JavaDocs并创建“继承的操作”列表时没有问题，我无法弄清楚是什么这实现了。
唯一的想法是，最初调用是在Session中，然后在创建特定子类时移动到QueueSession，尽管那时我希望在大写的文档中看到一些内容。但这只是猜想。
所以问题是： 是否有令人信服的理由在子接口中重新声明方法？
答案 0 :(得分：14)
在为Sun工作时偶尔看到这种情况，我可以告诉你它是如何发生的。有人用一些方法定义了一个接口，比如Alice。许多开发人员实现了该接口。
一段时间后，它意识到他们需要一些其他接口，称之为Bob，它有Alice的一部分方法，以便它可以作为另一个的基本接口。界面，克拉拉。
如果将Alice的方法移动到Bob中，则会破坏实现Alice的所有代码;你必须回去并至少重新编译一大堆你可能不拥有的代码，并且由于政治原因不能破解。
所以你没有。
答案 1 :(得分：4)
在Java 5中，您可以通过使其更具体来更改覆盖方法的返回类型。 更常见的是文档不同，因此必须再次声明该方法。
但是，如果方法和文档相同，则不需要它。但是，您将看到大量不严格需要的代码。它可能需要一次，但有些东西已经改变，因此不再需要它。它很可能永远不需要，但之所以这样做是因为开发人员认为在实际上没有良好的基础时需要做些什么。
顺便说一句：不同的人对于需要什么或者有什么方法有不同的看法，或者更好地明确。答案 2 :(得分：2)
我从来没有见过这样的好理由。我见过的最好的是：
我不喜欢这两个建议。我认为可能的原因是，在编写代码时，接口是在抽象类之前编写的，开发人员并不打算删除重复的工具。
永远不要低估开发人员的懒惰： - ）
最后不会造成任何伤害，除非在类加载时，加载具有重复接口的类可能需要更长的时间。
答案 3 :(得分：0)
我会说不，没有理由这样做。我可以想象在一些代码的演变过程中可能会发生这种情况。采用现有接口并从中拉出较小的超级接口并不罕见。在那种情况下，我可以想象离开现有的界面，只需将其更改为从新界面扩展。
答案 4 :(得分：-1)
我知道的唯一原因是扩大方法的可见性（即从受保护的克隆到公共的），但这似乎不是这种情况。