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

Question

Este es un ejemplo usando múltiples herencia de interfaces en Java y que hay un problema.

Tenga en cuenta que estoy totalmente sé por qué hay un problema y esto no es el punto de mi pregunta. La pregunta es acerca de cómo se nombra este particular ambigüedad múltiple herencia de interfaces, si hay un nombre para él.

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, sé que esto no es el mismo problema aquí: ese no es el punto. El punto es que un nombre se ha acuñado en ese caso anterior.

Y me gustaría saber si existe un nombre para el tema que estoy a punto de describir.

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

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

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

interface MI extends A, B {...}

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

No se puede hacer eso, ya que:

  

tipos A y B son incompatibles; ambos   definir c () pero con retorno no relacionado   Tipo

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

Answer 1

No estoy seguro de que es un nombre específico para ello, o al menos no parece que sea muy de uso general. Se trata de "sólo" un problema de la asignación implícita de métodos de interfaz a métodos de clase; si usted podría tener sobrecargas que difieren sólo en los tipos de retorno, no habría ningún problema. Así se llega a un / sobrecarga / problema de asignación método implícito firma.

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

Sólo una nota lateral, C # permite implementaciones de interfaces explícitas, que se ocupa de este problema.

Answer 2

JLS §6.4. 4, los miembros de un tipo de interfaz llama a tales miembros superinterfaz duplicados ambigua , y requiere un error en tiempo de compilación. Me esperaba algo colorido como el href="http://en.wikipedia.org/wiki/Beaujolais_effect" rel="nofollow Beaujolais Efecto , Heisenbug , et al . Tal vez two's-a-multitud

Answer 3

Asimismo, no conozco ningún nombre específico para este problema. Siempre que arised se describe en una frase que contiene las palabras tipo de retorno incompatibilidad en algún momento. También se podría llamar la Mapa / Set de incompatibilidad ya que este es uno de los ejemplos más prominentes y molestos en las bibliotecas de clases de Java. Esto hace que sea imposible tener la misma clase implemente mapa, así como conjunto o una colección sólo porque Mapa define un remove (Object) método con un tipo de retorno diferente a la 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 4

Me atrevo a llamar a esto un problema de herencia múltiple, ya que se limitan a describir las interfaces bien, interfaz - un conjunto de métodos de una clase que implementa debe definir - en lugar de cualquier aplicación. La extensión de una interfaz con otras interfaces en realidad no significa hereda los subinterface de la superinterfaz, sino más bien que la subinterfaz es, en esencia, una concatenación de los métodos definidos en los dos.

Si una tercera interfaz se utiliza para extender la subinterfaz y proporciona una declaración de método en conflicto, es esencialmente el mismo que si sólo hubiera proporcionado los mismos dos métodos opuestos de la misma interfaz.

Answer 5

No recuerdo si alguna vez he visto ningún nombre para esto. En del lenguaje Java especificación no hay un nombre para este tampoco.

Answer 6

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 requieren los métodos de la clase que implementan dos elementos de interfaz que sólo difieren en el tipo de retorno a tener nombres diferentes, ello no impide su capacidad para implementar elementos de interfaz con el mismo nombre.

Si una interfaz hereda dos interfaces con los miembros en conflicto, una clase que implementa la interfaz de material compuesto puede implementar los miembros como si se había heredado las interfaces en conflicto directamente. Los consumidores de la interfaz combinado generalmente no serán capaces de utilizar los miembros de cualquiera de interfaz de componente sin una conversión de la referencia a uno de los otros tipos de interfaz, pero el reparto en cuestión será considerado como un upcast en lugar de un abatido.

El esquema implementado en .NET funciona muy bien allí. Desafortunadamente, no hay manera de hacer algo similar en Java. No sé que Java chirriará si una interfaz hereda otras interfaces con los miembros de conflicto, pero si es o no grazna en ese momento, no habría manera de producir una clase que podría ponerlo en práctica.

Answer 7

No creo que un nombre se ha definido debido a las interfaces en Java no pueden tener aplicación método, por lo tanto, se evita el problema ya que siempre hay una sola aplicación a un método específico y por lo tanto sin ambigüedad surgirá.

¿Me he perdido el punto o ¿Está hablando de la variable 'c'?