En Java, cuando una interfaz se extiende a otra, ¿por qué se volvería a declarar un método en una subinterfaz?

Question

He estado consultando la API JMS desde J2EE y encontré un comportamiento extraño en el que ciertos métodos que se declaran en una interfaz (por ejemplo, createQueue en Session) se vuelven a declarar en las subinterfaces como QueueSession y con documentación idéntica.

Dado que una subinterfaz "hereda" todas las declaraciones de métodos de la interfaz que hereda, y como la herramienta JavaDoc no tiene problemas para ordenar los JavaDocs de la subinterfaz y crear una lista de "operaciones heredadas", no puedo entender lo que esto logra

Lo único que se puede pensar es que inicialmente la llamada estaba en Session, y luego se movió a QueueSession cuando se creó la subclase específica, aunque entonces habría esperado ver algo en la documentación de la clase superior. Pero esto es solo conjetura.

Así que la pregunta es: ¿Hay alguna razón convincente para redeclarar un método en una subinterfaz?

Answer 1

Habiendo visto esto suceder en alguna ocasión mientras trabajaba para Sun, puedo decirle cómo suele suceder. Alguien define una interfaz, digamos Alice, con algunos métodos; muchos desarrolladores implementan esa interfaz.

Algún tiempo más tarde, se ha dado cuenta de que necesitan alguna otra interfaz, lo llaman Bob, que tiene un subconjunto de los métodos de Alice, con el fin de permitir que sirva como una interfaz de base para otra interfaz, Clara.

Si mueve los métodos de Alicia a Bob, rompe todo el código que implementa Alicia; tienes que volver y al menos recompilar una gran cantidad de código, algunos de los cuales no puedes tener, y por razones políticas no se puede romper.

Así que no es así.

Answer 2

Nunca he visto un buen razonamiento para esto. El mejor que he visto es que:

• Se deja en claro lo que es sin tener que ver el padre
• Esto hace que sea más fácil cambiar lo que la clase se extiende sin tener que averiguar qué interfaces se debe aplicar

No me gusta ninguna sugerencia. Creo que la causa probable es que, mientras se escribía el código, las interfaces se escribían antes que las clases abstractas y los desarrolladores no se molestaban en eliminar los implementos duplicados.

Nunca subestime la pereza de un desarrollador :-)

Al final no se haga daño a excepción de que en tiempo de carga de clase que probablemente lleva una fracción no apreciable de tiempo más largo para cargar una clase con interfaces duplicadas.

Answer 3

la única razón que conozco es para ampliar la visibilidad de un método (es decir, clonar de protegido a público), pero ese no parece ser el caso aquí.

Answer 4

Yo diría que no, no hay ninguna razón para hacer esto. Sin embargo, puedo imaginar algunas maneras en que esto podría suceder durante la evolución de algunos códigos. No es raro tomar una interfaz existente y extraer una súper-interfaz más pequeña. En esa circunstancia, puedo imaginarme abandonar la interfaz existente pero simplemente cambiarla para extenderla desde una nueva interfaz.

Answer 5

En Java 5 puede cambiar el tipo de devolución de un método de anulación, haciéndolo más específico. Más comúnmente, la documentación es diferente, por lo que el método debe declararse nuevamente.

Sin embargo, si el método y la documentación son los mismos, no es necesario. Sin embargo, verá muchos códigos que no son estrictamente necesarios. Es posible que se haya necesitado una vez, pero algo ha cambiado y ya no es necesario. Es bastante probable que nunca fue necesario, pero se hizo porque el desarrollador pensó que había que hacer algo cuando en realidad no había una buena base para ello.

BTW: Diferentes personas tienen diferentes puntos de vista sobre lo que se necesita o lo que se debe tener para explicárselo.