Diskussion:Diamond-Problem

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 19. Dezember 2018 um 22:49 Uhr durch imported>Markus Bodensee(1697967) (Signaturnachtrag, neue Beiträge nach unten).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Twin

Das Twin-Pattern ist zweifellos ein interessantes Pattern. Leider geht aus dem Lemma nicht so richtig hervor, was es zur Lösung des Diamond-Problems beitragen kann. In dem referenzierten Papier wird gar kein Bezug auf das Diamond-Problem genommen. -- Mulno 09:12, 21. Mär. 2007 (CET)

Ich habe das Pattern (und auch das ebenso irrelevante Strategie-Pattern) entfernt. --Mulno 20:06, 18. Aug. 2007 (CEST)

Überarbeitung

(Bitte nicht löschen, ich möchte diesen Teil als Vorbereitung für eine überarbeitete Version des Artikels nehmen.) Sollte man nicht einmal darauf eingehen, das es zwei Arten von Problemen geben kann.

Die Attribut-Verdoppelung und die Namenskonflikte, Beispiel in einer nicht näher bezeichneten Programmiersprache:

class Base {
  protected int gewicht;

  public void setGewicht(int neuesGewicht){
     gewicht = neuesGewicht;
  }

  public int getGewicht(){
     return gewicht;
  }

  public void foo(){
     echo "ich bin Base.foo";
  }

  public void bar(){
     echo "ich bin Base.bar";
  }
}

class ChildLeft extends Base{
   public ortho1(){
     // irgendeine Funktionalität (orthogonal zu ChildRight)
  }

   public foo(){
     echo "ich bin ChildLeft.foo";
  }

   public bar(){
     echo "ich bin ChildLeft.bar";
  }
}

class ChildRight extends Base {
   public ortho2(){
     // irgendeine Funktionalität (orthogonal zu ChildLeft)
  }

   public bar(){
     echo "ich bin ChildRight.bar";
  }
}

class Together extends ChildLeft, ChildRight {
}

Hier können viele Themen diskutiert werden. Z.B.

  • Welche der Implementierungen wird aufgerufen für Together.foo(), Together.bar()? (Namenskonfliktauflösung Eiffel)
  • Gibt es in Together zweimal den Wert member? (virtual Vererbung in C++)
  • Was passiert, wenn man stattdessen Interfaces benutzt? (Hilft nicht für den Namenskonflikt)

DIe spezifischen Probleme (doppelte Member Variablen und Ambiguität der ausgeführten Funktion) müssen genauer beschrieben werden.

In den Abschnitt Lösungen gehören die Lösungen, die mehrfachvererbende Sprachen für die Probleme anbieten, die mit der Mehrfachvererbung und den Diamandstrukturen kommen. Alternativen zur Mehrfachvererbung wie "Zwillinge", "Strategie mit Interfaces" gehören meiner Meinung nach in den Artikel Mehrfachvererbung, bestenfalls sollten hier die Alternativen als ein "siehe auch" gelistet werden (Pflegeaufwand).

Es geht bei der Mehrfachvererbung immer darum Implementationsvererbung und/oder Interfacevererbung durchzuführen. Das Diamondproblem ist eigentlich nur ein Problem bei der Implementierungsvererbung. Was ist die Motivation dafür! Diese Fragestellung sollte im Artikel deutlich werden (wohl eher im Artikel Mehrfachvererbung).

Neue Artikelstruktur:

  • Vorstellung Diamandstruktur (Verweis auf die Motivation der Mehrfachvererbung)
  • Probleme daraus
    • doppelte Member
    • Ambiguität
  • Lösungen
    • Verzicht auf Mehrfachvererbung
    • mixin (Ruby)
    • Lösungen der mehrfachvererbenden Sprachen
      • public virtual (C++)
      • name resolution (Eiffel)
  • siehe auch (Alternativen zur Mehrfachvererbung)

Was haltet ihr davon? -- 13:26, 17. Okt. 2007 (CEST) (unvollständig signierter Beitrag von Mstolt (Diskussion | Beiträge) 14:15, 20. Okt. 2007 (CEST))

Artikel völlig veraltet

Schaut die Englische Version dieses Artikels an. Das stehen die Lösungen und mit welchen Programmiersprachen es sie wie gibt. -- STEFFENW 13:13:00, 21. Nov. 2012 (CET)