在Java中,当一个接口扩展另一个接口时,为什么要在子接口中重新声明一个方法?

Uri*_*Uri 8 java interface

我一直在从J2EE查看JMS API,并发现了一个奇怪的行为,其中在接口中声明的某些方法(例如,Session中的createQueue)在子接口(例如QueueSession)中再次声明,并且具有相同的文档.

由于子接口"继承"它继承的接口的所有方法声明,并且由于JavaDoc工具在排序子接口的JavaDocs并创建"继承的操作"列表时没有问题,因此我无法弄清楚它实现了什么.

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

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

Cha*_*tin 14

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

一段时间后,它意识到他们需要一些其他接口,称之为Bob,它有Alice的一部分方法,以便允许它作为另一个接口的基本接口,Clara.

如果将Alice的方法移动到Bob中,则会破坏实现Alice的所有代码; 你必须回去并至少重新编译一大堆你可能不拥有的代码,并且出于政治原因不能破解.

所以你没有.

  • 这个解释没有丝毫意义。如果鲍勃有爱丽丝方法的子集,为什么它应该是爱丽丝的子类型,最终会拥有爱丽丝方法的*所有*,而不仅仅是一个子集?更重要的是,*这甚至不能解释为什么 Bob 重新声明这些方法*。这就是问题的全部内容。不是关于错误的子类型关系的假设场景(您知道任何现实生活中的例子吗?),而是为什么子类型重新声明它也继承的方法。 (2认同)

Pet*_*rey 6

在 Java 5 中,您可以通过使其更加具体来更改重写方法的返回类型。更常见的是,文档不同,因此必须重新声明该方法。

但是,如果方法和文档相同,则不需要。但是,您会看到大量并非严格需要的代码。有可能曾经需要它,但某些内容发生了变化,因此不再需要它。它很可能从未被需要,但却被完成,因为开发人员认为需要做一些事情,而实际上并没有良好的基础。

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