Java: ¿cómo se llama a esta ambigüedad de herencia múltiple?

Question

Aquí hay un ejemplo que usa herencia de interfaz múltiple en Java y hay un problema.

Tenga en cuenta que sé completamente por qué hay un problema y este no es el punto de mi pregunta. La pregunta es acerca de cómo nombras esta ambigüedad particular de herencia de interfaz múltiple, si hay un nombre para ella.

Por ejemplo, en C++, la ambigüedad que surge cuando se utiliza herencia múltiple ejecución y no se puede determinar el método a utilizar sobrescrito se llama el "problema de diamante":

http://en.wikipedia.org/wiki/Diamond_problem

Ahora, una vez más, me Sé que este no es el mismo problema aquí: ese no es el punto. El punto es que se ha acuñado un nombre en ese caso anterior.

Y me gustaría saber si existe un nombre para el problema que voy a describir.

He aquí un ejemplo de otro tipo de herencia múltiple, donde una interfaz hereda de otras dos interfaces que tienen una incompatibles tipo de retorno método:

interface A { 
    void a(); 
    Integer c(); 
} 

interface B { 
    void b(); 
    Long c(); 
} 

interface MI extends A, B {...} 

(aviso múltiple herencia de interfaces en el trabajo usando la 'extiende' palabra clave)

no se puede hacer eso, porque:

tipos A y B son incompatibles; tanto definen c() pero con retorno sin relación tipo

se ha acuñado un nombre para describir esa situación?

Answer 1

No estoy seguro de que haya un nombre específico para él, o al menos no parece ser muy común. Es "solo" un problema de la asignación implícita de métodos de interfaz a los métodos de clase; si pudiera tener sobrecargas que difieran solo en los tipos de devolución, tampoco habría ningún problema. Por lo tanto, se reduce a un problema de mapeo de firma/sobrecarga/implícito.

En el libro en línea "Pensando en Java", tampoco hay un nombre para él. http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ310_001.htm

Solo una nota al margen, C# permite implementaciones de interfaz explícitas, lo que soluciona este problema.

Answer 2

No creo que se haya definido un nombre porque las interfaces en Java no pueden tener implementación de método, por lo que se evita el problema ya que siempre hay una sola implementación para un método específico y por lo tanto no surgirá ninguna ambigüedad.

¿He perdido el punto o está hablando de la variable 'c'?

Answer 3

No me cabe duda de que se trata de un problema de herencia múltiple, porque las interfaces simplemente describen bien, la interfaz (un conjunto de métodos que debe definir una clase de implementación) en lugar de cualquier implementación. La extensión de una interfaz con otras interfaces no significa realmente que la subinterfaz herede de la superinterfaz, sino que la subinterfaz es, en esencia, una concatenación de los métodos definidos en las dos.

Si se utiliza una tercera interfaz para extender la subinterfaz y proporciona una declaración de método conflictiva, es esencialmente la misma que si acabara de proporcionar los mismos dos métodos conflictivos en la misma interfaz.

Answer 4

No recuerdo si alguna vez he visto algún nombre para esto. En Java Language Specification tampoco hay un nombre para esto.

Answer 5

JLS §6.4.4, The Members of an Interface Type llamadas miembros superinterfaz tales duplicados ambiguas, y requiere un error en tiempo de compilación. Esperaba algo colorido como el Beaujolais Effect, Heisenbug, et al. ¿Tal vez two's-a-crowd?

Answer 6

Tampoco conozco ningún nombre específico para este problema. Siempre que surgió, se describió en una oración que contenía las palabras incompatibilidad de tipo de devolución en algún momento. También puede llamarlo Map/Set incompatibilty ya que este es uno de los ejemplos más destacados y molestos en las bibliotecas de clases de Java. Hace que sea imposible tener el mismo mapa Implementar clase, así como Establecer o Colección, simplemente porque Map define un método eliminar (Objeto) con un tipo de devolución diferente al de Colección.

public interface Collection<E> extends Iterable<E> { 
    boolean remove(Object o); 
} 
public interface Set<E> extends Collection<E> { 
} 
public interface Map<K,V> { 
    V remove(Object key); 
} 

Answer 7

El problema que describes existe en .NET, así como Java, pero tiene una solución simple que hay: el marco .NET permite a una clase práctica un miembro de interfaz utilizando un miembro de la clase con un nombre diferente. Por lo tanto, aunque se requiere que los métodos de clase que implementan dos miembros de interfaz que difieren solo en el tipo de retorno tengan diferentes nombres, eso no excluye su capacidad de implementar miembros de interfaz con el mismo nombre.

Si una interfaz hereda dos interfaces con miembros en conflicto, una clase que implemente la interfaz compuesta puede implementar los miembros como si hubiera heredado las interfaces en conflicto directamente. Los consumidores de la interfaz combinada generalmente no podrán usar los miembros de cualquiera de las interfaces de los componentes sin convertir la referencia a uno de los otros tipos de interfaz, pero el elenco en cuestión se considerará un upcast en lugar de un downcast.

El esquema implementado en .NET funciona muy bien allí. Desafortunadamente, no hay forma de hacer algo similar en Java. No sé si Java graznará si una interfaz hereda otras interfaces con miembros en conflicto, pero si grazna o no en ese punto, no habría forma de producir una clase que pueda implementarlo.