Eine Frage des Designs

[babuschka]

Hallo,

mich plagt gerade eine Design Frage in meinem Java-Code. Um mein Problem zu verdeutlichen, erkläre ich es an einem einfachen Beispiel:

Angenommen ich möchte ein Interface "Auto" anbieten, welches von zwei Klassen "VW" und "Opel" implementiert wird. Nun soll es in meinem Interface "Auto" eine Methode geben, die lautet "public void verarbeite(Tür t)".
Dabei ist "Tür" wiederum ein Interface, welches von zwei Klassen "VW-Tür" und "Opel-Tür" implementiert wird.

Das Inteface "Tür" soll dabei sicherstellen, dass jeder Tür-Typ gewisse Methoden mit sich bringt.

Wie man es sich bereits denken kann, soll ein Objekt der Klasse "VW" für die Methode "verarbeite" eigentlich nur Türen des Typs "VW-Tür" bekommen. Das Interface würde aber auch den Typ "Opel-Tür" erlauben.
Das gefällt mir nicht besonders, weil das Interface alle Arten von Türen zulässt, jedoch eigentlich jede Klasse nur ihre spezielle Tür bekommen sollte. Man müsste als hier evtl eine Fehlermeldung ausgeben, z.B. "ClassCastException", falls man stur die übergebene Tür castet zur spezifischen.

Was meint ihr dazu? Ist das trot evtl. "ClassCastException" ein sauberes Desgin oder lässt sich das verbessern?
Im Kommentar zur Funktion "verarbeite" sollte dann natürlich darauf hingewiesen werden, dass ein cast stattfindet.

Eine Überlegung wäre, statt ein "Tür" Interface, generics im Interface von "Auto" zu verwenden, so dass man die Methode "verarbeite(T t)" erhält. Die Klasse "VW" hätte dann also die Methode "verarbeite(VW-Tür t)".
Der Nachteil ist jedoch, dass nicht sichergestellt ist, dass jeder Tür-Typ gewisse Methoden mit sich bringt.

Ich bin gespannt auf jede Art von Vorschlag und Anregung. 🙂

Schöne Grüße, Rouven

 

[Gast2]

Eine Überlegung wäre, statt ein "Tür" Interface, generics im Interface von "Auto" zu verwenden, so dass man die Methode "verarbeite(T t)" erhält. Die Klasse "VW" hätte dann also die Methode "verarbeite(VW-Tür t)".
Der Nachteil ist jedoch, dass nicht sichergestellt ist, dass jeder Tür-Typ gewisse Methoden mit sich bringt.

Warum nicht? VWTür implementiert doch weiterhin das Interface Tür, also ist doch sichergestellt das es die Methoden die in Tür definiert sind gibt.

 

[Marco13]

Eine Überlegung wäre, statt ein "Tür" Interface, generics im Interface von "Auto" zu verwenden, so dass man die Methode "verarbeite(T t)" erhält. Die Klasse "VW" hätte dann also die Methode "verarbeite(VW-Tür t)".
Der Nachteil ist jedoch, dass nicht sichergestellt ist, dass jeder Tür-Typ gewisse Methoden mit sich bringt.

Ja... äh .. doch ???:L Vermutlich hast du sowas nicht bedacht wie

interface Auto<T[b] extends[/b] Tür>
{
   void bla(T tür);
}

Auto<String> wurst = null; // Geht nicht...

 

[babuschka]

Danke für eure Antworten !

Ja... äh .. doch ???:L Vermutlich hast du sowas nicht bedacht wie

interface Auto<T[b] extends[/b] Tür>
{
   void bla(T tür);
}

Auto<String> wurst = null; // Geht nicht...

Stimmt, das hatte ich nicht bedacht. Danke, das löst das Problem sehr gut. 🙂

Frage: Hier wurde "extends" benutzt, jedoch handelt es sich bei Tür um ein Interface, ist extends nicht für Unterklassen vorbehalten? Hätte hier eher ein "implements" erwartet, was aber an dieser Stelle in einer Fehlermeldung endet.

Schöne Grüße, Rouven

 

[Landei]

Bei Generics gibt es nur die Muster:
<T extends AClass>,
<T extends AnInterface>,
<T extends AClass & AnInterface & AnotherInterface> und
<T extends AnInterface & AnotherInterface & ACompletelyDifferentInterface>
Kein implements. Isso.

 

[DaveX]

Aprops "Design" - ich denke hier könnte ein "Design" Pattern eingesetzt werden und zwar das Factory Pattern welches je nach Fahrzeugtyp entsprechendes Tür Object liefert.

 

[Marco13]

Bei Generics gibt es nur die Muster:
<T extends AClass>,
<T extends AnInterface>,
<T extends AClass & AnInterface & AnotherInterface> und
<T extends AnInterface & AnotherInterface & ACompletelyDifferentInterface>
Kein implements. Isso.

... und das ganze natürlich noch munter gemischt mit "super" 😀