Kann das Diamant-Problem wirklich gelöst werden?

Was Sie sehen, ist, wie Verstöße gegen die Liskov-Substitution-Prinzip machen es wirklich schwer zu haben, eine funktionierende, logische Objekt-orientierte Struktur.

Im Grunde, (öffentlich) Vererbung sollte nur der schmale Zweck der Klasse ist, nicht verlängern. In diesem Fall, durch Erben von zwei Arten von Fahrzeugen Sie sind in der Tat die Verlängerung der Zweck, und wie Sie bemerkt, es funktioniert nicht - bewegen sollte ganz anders werden für ein Wasser-Fahrzeug als für ein road-Fahrzeug.

Sie könnte stattdessen Aggregat ein Wasser-Fahrzeug und eine Boden-Fahrzeug-Objekt in Ihrem Amphibienfahrzeug und entscheiden extern, welche von den beiden wird es werden je nach Aktueller situation.

Alternativ könnte man entscheiden, dass das "Fahrzeug" - Klasse ist unnötig Generika und Sie werden über getrennte Schnittstellen für die beiden. Das löst nicht das problem für Ihre Amphibienfahrzeug auf seine eigene, obwohl - wenn Sie rufen Sie die Bewegung, die die Methode "move" in beide Schnittstellen haben, werden Sie noch Probleme haben. Also ich würde vorschlagen, aggregation statt Vererbung.

InformationsquelleAutor der Antwort Joris Timmermans

In deinem Beispiel move() gehört zu den Vehicle - Schnittstelle und definiert den Vertrag "gehen von Punkt A zu Punkt B".

Wenn GroundVehicle und WaterVehicle erweitern Vehicle Sie Erben implizit dieses Vertrages (Analogie: List.contains erbt seinen Vertrag aus Collection.contains - stellen Sie sich vor, wenn es etwas anderes angegeben!).

So, wenn der Beton AmphibianVehicle implementiert move() der Vertrag, es muss wirklich Respekt Vehicle's. Es ist ein Diamant, aber den Vertrag nicht ändern, ob Sie erwägen, eine Seite, die Diamant-oder die andere (oder ich würde anrufen, dass ein design-problem).

Wenn Sie den Vertrag von "verschieben" zu verkörpern, der Begriff der Oberfläche, nicht definieren, es in einer Art, die nicht Modell dieser Vorstellung:

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

(Analogie: get(int)'s Vertrag definiert, durch die List - Schnittstelle. Könnte es nicht vielleicht sein, definiert durch Collection als Sammlungen sind nicht notwendigerweise geordnete)

Oder umgestalten generische Schnittstelle zum hinzufügen von Begriff:

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

Das einzige problem sehe ich bei der Implementierung mehrerer Schnittstellen ist bei beiden Methoden von völlig unabhängigen Schnittstellen passieren zu kollidieren:

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() {
        //???
    }
}

Dann aber wäre das nicht ein Diamant. Mehr wie eine upside-down-Dreieck.

InformationsquelleAutor der Antwort Olivier

Ich weiß nicht Java, aber ob die Schnittstellen B und C Erben von der Schnittstelle A -, und D-Klasse implementiert die Interfaces B und C, dann D-Klasse nur implementiert die move-Methode einmal, und es ist A. Bewegen, die es umsetzen sollten. Wie Sie sagen, der compiler hat kein problem mit dieser.

Aus dem Beispiel, das Sie geben in Bezug auf die AmphibianVehicle Umsetzung GroundVehicle und WaterVehicle, dies könnte leicht gelöst werden, indem das speichern einer Referenz auf die Umwelt, zum Beispiel, und freilegen einer Oberfläche Eigenschaft auf die Umwelt, dass die Move-Methode von AmphibianVehicle würde inspizieren. Keine Notwendigkeit, für diese als parameter übergeben werden.

Du hast Recht in dem Sinne, dass es etwas ist, was für den Programmierer zu lösen, aber es ist zumindest kompiliert und sollte nicht sein 'problem'.

InformationsquelleAutor der Antwort Patrick McDonald

Wenn ich weiß, eine AmphibianVehicle
interface, erbt von
GroundVehicle und WaterVehicle, wie
würde ich es implementieren der Methode move ()?

Würden Sie unterstützen die Implementierung geeignet für AmphibianVehicles.

Wenn ein GroundVehicle bewegt sich "anders" (D. H. andere Parameter akzeptiert, als eine WaterVehicle), dann AmphibianVehicle erbt zwei verschiedene Methoden, eine für Wasser, eine für auf dem Boden. Wenn dies nicht möglich ist, dann AmphibianVehicle sollte nicht Erben aus GroundVehicle und WaterVehicle.

Ist ein Diamant-problem ist immer die Ursache
bad-class-design und etwas
weder der Programmierer noch der compiler muss
zu lösen, denn es sollte nicht existieren
in den ersten Platz?

Wenn es aufgrund von schlechtem Klassen-design, ist es der Programmierer braucht, um es zu lösen, da der compiler nicht weiß, wie.

InformationsquelleAutor der Antwort eljenso

Ich glaube nicht, dass die Verhinderung der konkreten mehrfache Vererbung ist in Bewegung das problem, dass der compiler den Programmierer. In dem Beispiel, das Sie Gaben, wäre es immer noch notwendig sein, für die der Programmierer angeben, um dem compiler die Implementierung zu verwenden. Es gibt keinen Weg, der compiler könnte erraten, welche die richtige ist.

Für Ihre Amphibien-Klasse, könnte man hinzufügen, eine Methode, um zu bestimmen, wenn das Fahrzeug zu Wasser oder zu land und die Nutzung dieser entscheidet über die move-Methode verwenden. Dies wird die Erhaltung der parameterlosen Schnittstelle.

move()
{

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

InformationsquelleAutor der Antwort Dave Turvey

Wenn move() semantische Unterschiede basierend auf Boden oder Wasser (eher als GroundVehicle und WaterVehicle Schnittstellen sowohl sich selbst als Erweiterung GeneralVehicle Schnittstelle, die den move () - Signatur), aber es wird erwartet, dass Sie mix und match-Boden und Wasser-Implementierer dann ist dein Beispiel ist wirklich einer der schlecht entwickelten api.

Das eigentliche Problem ist, wenn der name Kollision, effektiv, zufällig.
zum Beispiel (sehr synthetisch):

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

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

Wenn Sie eine Jacke, die Sie wünschen, werden beide ein Kleid und zerstörbare Sie haben einen Namen Kollision auf der (berechtigterweise genannt) tragen Methode.

Java hat keine Lösung für dieses (das gleiche gilt für mehrere andere statisch typisierten Sprachen). Dynamische Programmier-Sprachen haben ein ähnliches Problem, auch ohne das diamond oder Erbe, es ist nur ein name Kollision (eine inhärente Problem mit Duck Typing).

.Net hat das Konzept der explizite Schnittstellenimplementierungen wobei eine Klasse definieren können zwei Methoden den gleichen Namen und Signatur so lange, wie beide markiert sind, zu zwei verschiedenen Schnittstellen. Die Bestimmung der jeweiligen Methode zu nennen ist, basierend auf compile-Zeit bekannt-interface die variable (oder wenn durch Reflexion von der expliziten Wahl der angerufene)

Dass vernünftige, wahrscheinlich, Kollisionen mit Namen, die sind so schwer zu bekommen und, dass java wurde nicht an den Pranger gestellt als unbrauchbar für die Bereitstellung nicht die explizite Schnittstellenimplementierungen würde vorschlagen, dass das problem nicht eine Bedeutung für die Reale Welt verwenden.

InformationsquelleAutor der Antwort ShuggyCoUk

Das problem wirklich existiert. In der Stichprobe der AmphibianVehicle-Klasse benötigen weitere Informationen - die Oberfläche. Meine bevorzugte Lösung ist das hinzufügen einer getter - /setter-Methode für die AmpibianVehicle-Klasse, um die Oberfläche verändern-Mitglied (enumeration). Die Umsetzung könnte jetzt das richtige zu tun und der Klasse bleiben gekapselt.

InformationsquelleAutor der Antwort p2u

Das Diamant-problem in C++ ist bereits gelöst: Einsatz der virtuellen Vererbung. Oder noch besser, seien Sie nicht faul und zu Erben, wenn es nicht nötig ist (oder unvermeidlich). Wie für das Beispiel, das Sie Gaben, könnte dies gelöst werden, indem Sie neu definieren, was es bedeutet, in der Lage zu fahren, auf der Erde oder im Wasser. Hat die Fähigkeit, sich im Wasser zu bewegen wirklich zu definieren, eine Wasser-basierte KFZ-oder ist einfach nur etwas, das Fahrzeug ist in der Lage, das zu tun? Ich würde eher denken, dass die move () - Funktion, die Sie beschrieben hat, irgendeine Art von Logik dahinter, die sich fragt "wo bin ich und kann ich eigentlich hierher gezogen?" Das entspricht einem bool canMove() Funktion, die abhängig vom aktuellen Zustand und die inhärenten Fähigkeiten des Fahrzeugs. Und Sie brauchen keine mehrfache Vererbung um dieses problem zu lösen. Verwenden Sie einfach ein mixin, das beantwortet die Frage in verschiedener Weise, je nachdem, was möglich ist und nimmt die übergeordnete Klasse als template-parameter, damit die virtuelle Funktion canMove wird sichtbar durch die Vererbungskette.

InformationsquelleAutor der Antwort Michel

Schnittstelle Ein
{
void add();
}

interface B extends A
{
void add();
}

interface C extends A
{
void add();
}

class D implements B,C
{

}

Ist es nicht Diamant-problem.

InformationsquelleAutor der Antwort Nirupma