Polymorphismus bei Arrays

[speck12]

Hallo allerseits,

eigentlich dachte ich, dass ich den Polymorphismus grundlegend verstanden habe, aber jetzt komme ich nicht weiter.

Folgendes Problem:

ich erstelle mir ein Array von Components und lege darin eine List und ein Panel ab.
Wenn ich jetzt auf das Panel zugreifen will, steht mir allerdings nicht die Methode add(Component comp) zur verfügung?!

public void set_comp_array(Component[] c){
		c[0] = init_list();      // die init_xx methoden liefern jeweils eine List bzw ein Panel zurück
		c[1] = init_panel1();
		c[2] = init_panel2();
}


public void set_layout(Applet a, Component[] c){
		c[1].add(c[0]);

}

Die add Methode wird nicht akzeptiert.

Über Hilfe wäre ich sehr dankbar

Mit freundlich Grüßen

 

[Marco13]

An der Stelle weiß er nicht mehr, dass dort ein Panel drin liegt. Das ist ein Array von Components. Dort könnte auch eine Component liegen, die KEIN Panel ist - wie sollte man darauf dann "add" aufrufen?

Abhilfe: Entweder mit instanceof überprüfen, ob dort ein Panel ist, und ggf. casten (nicht so schön), oder einen anderen Ansatz überlegen....

 

[maki]

Wenn ich jetzt auf das Panel zugreifen will, steht mir allerdings nicht die Methode add(Component comp) zur verfügung?!

java.awt.Component bietet keine add(Component comp) Methode.

 

[speck12]

hmm,

gibt es denn irgendeine andere Möglichkeit, verschiedene Components in einer Liste oder einem Array mitzuführen, bei der die Unterklasse direkt ansprechbar ist?

 

[Taggert]

Was ich nicht verstehe, warum Du überhaupt Component nimmst, wenn eh sicher ist, dann nur JPanels in den Array eingefügt werden sollen. Ansonsten mit instanceof prüfen. Um mal ganz naiv zu fragen: Warum sind Deine Arrays vom Typ Component und nicht vom Typ JPanel. Soweit ich Dich verstanden habe, sind da doch eh nur JPanels drin.

Vielleicht denke ich schon zu objektorientiert, aber ich weiss wirklich nicht, was Du genau willst. Du musst Dir doch zuerst überlegen, ob Deine verwendetet Klasse diese Schnittstelle hat, bevor Du einen Ansatz wählst, der diese (nicht vorhandene) Schnittstelle implementiert.

Da wir hier bei den Anfängerfragen sind, würde ich Dir auch einen Ansatz mit instanceof empfehlen - ist wohl am einfachsten, wenn auch nicht wirklich schön.

 

[ARadauer]

Methoden schreibt man camelCase ... setCompArray

 

[SlaterB]

verwende ein Array oder eine Liste einer neuen Klasse Xy, darin Klassenattribute für JPanel, JLabel, .., was immer du da zusammenmischen willst,

dann Aufruf xyArray.getPanel() oder ähnliches

 

[Marco13]

Hm. Da stellt sich IMHO die Frage, wie viel ("Workaround"-) Aufwand gerechtfertigt ist, um ein instanceof zu vermeiden. Es gibt da IMHO verschiedene Stufen:

1. Einfach mit instanceof testen und casten. Nicht schön, aber minimaler Aufwand.
(Der Rest bezieht sich speziell auf eigene Klassen: )
2. Eine Methode "getType", die irgendwas zurückliefert, woran man den Typ erkennt. Ist eigentlich nur ein verstecktes (oder "anitizipiertes") instanceof
3. Irgenwas "double-dispatch"/IOC(?)-artiges: Alle Objekte implementieren eine Methode, die - übertragen auf das Beispiel, wo es um Components bzw. Container#add geht - eine Funktion erfüllen wie
elementInArray.addIfPossible(target);
und die kann dann implementiert sein, wie sie will (ggf. auch mit einer UnsupportedOperationException). Finde ich aus struktureller Sicht gar nicht so unschön, weil es recht flexibel sein kann.
4. Spezielle Objekte in den Array legen, die Methoden haben wie "getComponent" und "getContainer" - und bei letzterer ggf. 'null' liefern - IMHO viel Aufwand für eine Vermeidung von 'instanceof'...
5. Alle Objekte implementieren Methoden wie "getAsComponent()" und "getAsContainer()", die entweder einfach 'this' returnen, oder, bei nicht-containern, eine UnsupportedOperationException werfen.
6. "Einfach" dafür sorgen, dass man die Panels, auf denen man add aufrufen kann, getrennt hält von den reinen Components, auf denen man NICHT add aufrufen kann....

Ich hatte schonmal spekuliert dass es (rein formal und theoretisch) möglich sein müßte, Programme IMMER so zu schreiben, das KEINE Laufzeit-Typabfragen erforderlich sind (einschließlich der ausgefeilteren Methoden wie pattern matching). Aber das konsequent durchzuziehen könnte unangemessenen Aufwand bedeuten....