¿Se puede resolver realmente el problema del diamante?

Question

Un problema típico en la programación de OO es el problema de los diamantes. Tengo una clase padre A con dos subclases B y C. A tiene un método abstracto, B y C lo implementan. Ahora tengo una subclase D, que hereda de B y C. El problema del diamante es ahora, ¿qué implementación usará D, la de B o la de C?

Las personas afirman que Java no conoce ningún problema con los diamantes. Solo puedo tener herencia múltiple con interfaces y dado que no tienen implementación, no tengo ningún problema con los diamantes. ¿Es esto realmente cierto? No lo creo. ver más abajo:

[ejemplo de vehículo eliminado]

es un problema de diamantes siempre la causa del mal diseño de la clase y algo que ni programador ni compilador necesita para resolver, ya que no debe existir en primer lugar?

---

Actualización: Tal vez mi ejemplo fue mal elegido.

Ver esta imagen

Diamond Problem http://cartan.cas.suffolk.edu/oopdocbook/opensource/src/multinheritance/PersonStudentTeacher.png

Por supuesto, puede hacer que la persona virtual en C++ y, por tanto, sólo tendrá una instancia de la persona en la memoria, pero el verdadero problema persiste en mi humilde opinión. ¿Cómo implementaría getDepartment() para GradTeachingFellow? Considere, él podría ser estudiante en un departamento y enseñar en otro. Entonces puede devolver un departamento u otro; no hay una solución perfecta para el problema y el hecho de que ninguna implementación pueda ser heredada (por ejemplo, Student y Teacher podrían ser ambas interfaces) no parece resolver el problema para mí.

Answer 1

Lo que está viendo es cómo las violaciones de Liskov Substitution Principle hacen que sea realmente difícil tener una estructura lógica orientada a objetos que funcione.
Básicamente, la herencia (pública) solo debe restringir el propósito de la clase, no extenderla. En este caso, heredando dos tipos de vehículos, de hecho estás ampliando el propósito, y como habrás notado, no funciona: el movimiento debería ser muy diferente para un vehículo acuático que para un vehículo de carretera.
En su lugar, puede agregar un vehículo acuático y un objeto de vehículo terrestre en su vehículo anfibio y decidir externamente cuál de los dos será apropiado para la situación actual.
Alternativamente, podría decidir que la clase "vehículo" es innecesariamente genérica y tendrá interfaces separadas para ambos. Sin embargo, eso no resuelve solo el problema de tu vehículo anfibio: si llamas al método de movimiento "moverse" en ambas interfaces, seguirás teniendo problemas. Así que sugeriría la agregación en lugar de la herencia.

Answer 2

La gente afirma Java no conoce el problema de diamante. Solo puedo tener herencia múltiple con interfaces y dado que no tienen implementación, no tengo ningún problema con los diamantes. ¿Es esto realmente cierto?

sí, ya que el control de la implementación de la interfaz en D. La firma del método es el mismo entre ambas interfaces (B/C), y ya que no tienen interfaces de aplicación - no hay problemas.

Answer 3

No sé Java, pero si las interfaces B y C heredan de la interfaz A, y la clase D implementa las interfaces B y C, entonces la clase D simplemente implementa el método de movimiento una vez, y es A.Move que debería implementar. Como dices, el compilador no tiene ningún problema con esto.

Según el ejemplo que da sobre AmphibianVehicle que implementa GroundVehicle and WaterVehicle, esto podría resolverse fácilmente almacenando una referencia al entorno, por ejemplo, y exponiendo una propiedad de superficie en el entorno que el método Move de AmphibianVehicle inspeccionaría. No es necesario pasar esto como un parámetro.

Tiene razón en el sentido de que es algo que el programador debe resolver, pero al menos compila y no debería ser un "problema".

Answer 4

que se dan cuenta de que este es un caso específico, no una solución general, pero suena como que necesita un sistema adicional para determinar el estado y decidir en qué tipo de movimiento() el vehículo llevaría a cabo.

Parece que en el caso de un vehículo anfibio, el que llama (digamos "acelerador") no tendría idea del estado del agua/suelo, sino un objeto intermedio como "transmisión" junto con " control de tracción "podría resolverlo, luego invocar move() con el movimiento de parámetro adecuado (ruedas) o mover (prop).

Answer 5

C# tiene explicit interface implementation para ocuparse parcialmente de esto. Al menos en el caso de que tenga una de las interfaces intermedias (un objeto de la misma ...)

Sin embargo, lo que probablemente sucede es que el objeto AmphibianVehicle sabe si está actualmente en agua o tierra, y hace lo correcto .

Answer 6

No hay un problema de diamante con la herencia basada en la interfaz.

Con la herencia basada en clases, las múltiples clases extendidas pueden tener diferentes implementaciones de un método, por lo que hay ambigüedad en cuanto a qué método se usa realmente en tiempo de ejecución.

Con la herencia basada en la interfaz solo hay una implementación del método, por lo que no hay ambigüedad.

EDITAR: En realidad, lo mismo se aplicaría a la herencia basada en la clase para los métodos declarados como Resumen en la superclase.

Answer 7

El problema realmente existe. En la muestra, AmphibianVehicle-Class necesita otra información: la superficie. Mi solución preferida es agregar un método getter/setter en la clase AmpibianVehicle para cambiar el miembro de la superficie (enumeración). La implementación ahora podría hacer lo correcto y la clase permanecer encapsulada.

Answer 8

No creo que la prevención de la herencia múltiple de hormigón traslade el problema del compilador al programador. En el ejemplo que usted dio, aún sería necesario que el programador especificara al compilador qué implementación usar. No hay forma de que el compilador adivine cuál es la correcta.

Para su clase de anfibios, puede agregar un método para determinar si el vehículo está en agua o tierra y utilizar este método de decisión sobre el movimiento. Esto preservará la interfaz sin parámetros.

move() 
{ 

    if (this.isOnLand()) 
    { 
    this.moveLikeLandVehicle(); 
    } 
    else 
    { 
    this.moveLikeWaterVehicle(); 
    } 
} 

Answer 9

Si sé que tiene una interfaz AmphibianVehicle , que hereda de GroundVehicle y WaterVehicle, cómo habría que implementarlo método move() es?

Proporcionar la implementación adecuada para AmphibianVehicle s.

Si un GroundVehicle mueve "diferente" (es decir, tiene diferentes parámetros que un WaterVehicle), entonces AmphibianVehicle hereda dos métodos diferentes, uno para el agua, uno para en el suelo. Si esto no es posible, entonces AmphibianVehicle no debe heredar de GroundVehicle y WaterVehicle.

es un problema de diamantes siempre la causa de diseño de clase malo y algo ni programador ni compilador necesita de resolver, ya que no debería existir en el primer lugar?

Si se debe al mal diseño de la clase, es el programador el que debe resolverlo, ya que el compilador no sabría cómo hacerlo.

Answer 10

Puede tener el problema de diamante en C++ (que permite herencia múltiple), pero no en Java o en C#. No hay forma de heredar de dos clases. Implementar dos interfaces con el mismo método de declaración no implica en esta situación, ya que la implementación del método concreto solo puede realizarse en la clase.

Answer 11

En este caso, probablemente sería más ventajoso tener AmphibiousVehicle como una subclase de Vehicle (hermano de WaterVehicle and LandVehicle), para evitar completamente el problema en primer lugar. Probablemente sea más correcto de todos modos, ya que un vehículo anfibio no es un vehículo acuático o un vehículo terrestre, es algo completamente diferente.

Answer 12

En su ejemplo, move() pertenece a la interfaz Vehicle y define el contrato "que va del punto A al punto B".

Cuando GroundVehicle y WaterVehicleVehicle se extienden, de forma implícita que heredan este contrato (analogía: List.contains hereda su contrato de Collection.contains - imaginar si se especifica algo diferente!).

Entonces cuando el hormigón AmphibianVehicle implementa move(), el contrato que realmente necesita respetar es Vehicle 's. Hay un diamante, pero el contrato no cambia si se considera un lado del diamante o el otro (o yo llamaría a eso un problema de diseño).

Si necesita el contrato de "movimiento" para encarnar la noción de superficie, no definirlo en un tipo que no modela esta noción:

public interface GroundVehicle extends Vehicle { 
    void ride(); 
} 
public interface WaterVehicle extends Vehicle { 
    void sail(); 
} 

(analogía: get(int) 's contrato está definido por la interfaz List.No podría ser definido por Collection, como colecciones no están necesariamente ordenados)

O refactorizarán su interfaz genérica para agregar la noción:

public interface Vehicle { 
    void move(Surface s) throws UnsupportedSurfaceException; 
} 

El único problema que veo la hora de implementar múltiples interfaces es cuando dos los métodos de interfaces totalmente no relacionadas chocan:

public interface Vehicle { 
    void move(); 
} 
public interface GraphicalComponent { 
    void move(); // move the graphical component on a screen 
} 
// Used in a graphical program to manage a fleet of vehicles: 
public class Car implements Vehicle, GraphicalComponent { 
    void move() { 
     // ??? 
    } 
} 

Pero eso no sería un diamante. Más como un triángulo invertido.

Answer 13

Si move() tiene diferencias semánticas basadas en Ground o Water (en lugar de GroundVehicle y WaterVehicle interfaces ambas extendiendo interfaz GeneralVehicle que tiene la firma move()) pero se espera que mezcle y combine tierra y implementadores de agua, entonces su ejemplo uno realmente es uno de una API pobremente diseñada.

El problema real es cuando la colisión del nombre es, efectivamente, accidental. por ejemplo (muy sintético):

interface Destructible 
{ 
    void Wear(); 
    void Rip(); 
} 

interface Garment 
{ 
    void Wear(); 
    void Disrobe(); 
} 

Si usted tiene una chaqueta que desea ser a la vez una prenda de vestir, y destructibles que tendrá una colisión nombre en la (legítimamente nombrado) desgaste método.

Java no tiene solución para esto (lo mismo es cierto para muchos otros lenguajes estáticos). Los lenguajes de programación dinámica tendrán un problema similar, incluso sin el diamante o la herencia, es solo una colisión de nombre (un problema potencial inherente con Duck Typing).

.Net tiene el concepto de explicit interface implementations mediante el cual una clase puede definir dos métodos del mismo nombre y firma, siempre que ambos estén marcados en dos interfaces diferentes. La determinación del método relevante para llamar se basa en la interfaz conocida de la variable conocida en tiempo de compilación (o si se refleja por la elección explícita del destinatario)

Que las colisiones de nombres razonables y probables son tan difíciles de obtener y que java no ha sido ridiculizado como inutilizable por no proporcionar las implementaciones explícitas de interfaz sugeriría que el problema no es significativo para el uso en el mundo real.

Answer 14

El problema del diamante en C++ ya está resuelto: use la herencia virtual. O mejor aún, no seas perezoso y heredes cuando no es necesario (o inevitable). En cuanto al ejemplo que dio, esto podría resolverse redefiniendo lo que significa ser capaz de conducir en el suelo o en el agua. ¿La capacidad de moverse a través del agua realmente define un vehículo a base de agua o es simplemente algo que el vehículo puede hacer? Prefiero pensar que la función mover() que describió tiene algún tipo de lógica que pregunta "¿dónde estoy y puedo mudarme aquí?" El equivalente de una función bool canMove() que depende del estado actual y las capacidades inherentes del vehículo. Y no necesitas herencia múltiple para resolver ese problema. Solo use un mixin que responda la pregunta de diferentes maneras dependiendo de lo que sea posible y tome la superclase como un parámetro de plantilla para que la función canMove virtual sea visible a través de la cadena de herencia.

Answer 15

En realidad, si Student y Teacher son ambas interfaces, de hecho resuelve su problema. Si son interfaces, entonces getDepartment es simplemente un método que debe aparecer en su clase GradTeachingFellow. El hecho de que las interfaces Student y Teacher hagan cumplir esa interfaz no es un conflicto en absoluto.Implementar getDepartment en su clase GradTeachingFellow satify ambas interfaces sin ningún problema de diamante.

PERO, como se señala en un comentario, esto no resuelve el problema de GradStudent enseñando/siendo un TA en un departamento, y siendo un estudiante en otro. La encapsulación es probablemente lo que usted quiere aquí:

public class Student { 
    String getDepartment() { 
    return "Economics"; 
    } 
} 

public class Teacher { 
    String getDepartment() { 
    return "Computer Engineering"; 
    } 
} 

public class GradStudent { 
    Student learning; 
    Teacher teaching; 

    public String getDepartment() { 
    return leraning.getDepartment()+" and "+teaching.getDepartment(); // or some such 
    } 

    public String getLearningDepartment() { 
    return leraning.getDepartment(); 
    } 

    public String getTeachingDepartment() { 
    return teaching.getDepartment(); 
    } 
} 

No importa que un GradStudent no significa conceptualmente "tienen" un maestro y el estudiante - encapsulación sigue siendo el camino a seguir.

Answer 16

El problema que está viendo en el ejemplo de Estudiante/Profesor es simplemente que su modelo de datos es incorrecto, o al menos insuficiente.

Las clases de Estudiante y Profesor combinan dos conceptos diferentes de "departamento" utilizando el mismo nombre para cada uno de ellos. Si desea utilizar este tipo de herencia, en su lugar debe definir algo como "getTeachingDepartment" en Teacher y "getResearchDepartment" en Student. Su GradStudent, que es a la vez Maestro y Estudiante, implementa ambos.

Por supuesto, dadas las realidades de la escuela de postgrado, incluso este modelo es probablemente insuficiente.

Answer 17

interfaz A { void add(); }

interfaz B extiende A { void add(); }

interfaz C extiende A { void add(); }

clase D implementa B, C {

}

no es problema de diamante.