Abstract Method & Generics

[OasisCritter]

Hallo,

ist es denn nicht möglich einer abstracten Methode einen generischen Parameter hinzuzufügen, sodass die Erben, immer mit ihren eigenen Typ arbeiten können. Sieht ein bissl komisch aus weil die Klasse vor dem generischen Parameter fehlt, so kanns nicht funktionieren aber wie ist die Alternative?

public abstract void setWindow( <? extends MyFrame> window);

Nehmen wir an der Erbe wäre childFrame extends MyFrame...

Nun sollte die Methode in childFrame so aussehn

public void setWindow( childFrame window);

Da die abstracte Methode "setWindow" in jedem Erben neu implementiert werden muss, sollte es diese Möglichkeit doch geben?


MfG

 

[diggaa1984]

warum nicht gleich MyFrame festlegen und in den Childklassen mit instanceof und cast arbeiten?

 

[OasisCritter]

warum nicht gleich MyFrame festlegen und in den Childklassen mit instanceof und cast arbeiten?

Weil casten unschön ist

 

[DerEisteeTrinker]

Ich kenn zwar nicht die genauen Hintergründe deiner Anwendung bzw. deines Quellcodes, aber probier es mal mit einem Interface.

public abstract void setWindow( IMyFrame window);

Mit dem Interface ist es dir ja egal, welches der eventuell vielen Kinder es ist. Wenn du dann iwann etwas bestimmtes brauchst, dann machst du halt einen cast.

 

[faetzminator]

Mit dem Interface ist es dir ja egal, welches der eventuell vielen Kinder es ist. Wenn du dann iwann etwas bestimmtes brauchst, dann machst du halt einen cast.

Natürlich, man denke nur an die List von 1.4
Warum sollte man etwas nicht machen, wenn es vorteilhaft, hübsch und nicht gerade zeitaufwändig ist?

 

[bygones]

Mit dem Interface ist es dir ja egal, welches der eventuell vielen Kinder es ist. Wenn du dann iwann etwas bestimmtes brauchst, dann machst du halt einen cast.

was - sorry - gelinde gesagt größter Unsinn ist... ein Interface zu deklarieren um dann wieder auf einen konkreten Typen zu casten - doppelter fehler.

@TE:
wenn deine Klasse Typparameter braucht dann mach die Klasse generisch

 

[DerEisteeTrinker]

@bygones

Ich programmiere schon seit mehreren Jahren mit Java und diesen Cast hinter einem Interface habe ich bisher immer nur in JUnit-Tests vollzogen, weil ich dann in den konkreten Objekten noch zusätzliche Möglichkeiten geschaffen habe, um die Inhalte darzustellen, ohne den Quelltext mit Log-Ausgaben zu überfrachten oder ewig und drei Tage den Debugger zu bemühen. Im reinen Produktiveinsatz habe ich es immer vermieden. Denn durch geschicktes Design brauche ich einen Cast garnicht.

Das es die ultimative Lösung ist, sag ich ja garnicht. Aber es ist eine von vielen Wegen nach Rom.

 

[bygones]

@EisteeTrinker

schau dir mal mocks / stubs / fakes an

 

[Marco13]

Im Zweifelsfall

abstract class Something<T extends MyFrame>
{
    public abstract void setWindow(T window);
}

 

[OasisCritter]

Im Zweifelsfall

abstract class Something<T extends MyFrame>
{
    public abstract void setWindow(T window);
}

Ja, aber so müssten ja alle Klassen von "Something" erben und nicht von MyFrame.
Und selbst dann, ist die folge, dass wenn ich "Something" erstmal initialisiert habe, dann haben alle Erben von "Something" den gleichen Parameter. Und da wären wir wieder am Anfang...

Bsp.: new Something<MyFrame>();

childFrame extends Something...

public class childFrame() { ...

     public void setWindow( MyFrame window);

}

##############################

Zu: EisteeTrinker:

Casten könnt ich auch mit den abstracten Methoden, dazu brauch ich nicht extra ein Interface.

 

[Marco13]

Das bezog sich darauf, wo die besagte Methode DRIN steht. An der Hierarchie ändert sich damit nichts.