JTree - Brett vor'm Kopp

[SamHotte]

Hi,

ich stell' mich grad ziemlich dämlich an beim Versuch, eine vernünftige Hierarchie für folgendes zu finden:
1. ich benötige verschiedene Baumstrukturen, die ich allesamt grafisch darstellen möchte (mit eigenen JTrees, die verschiedene Renderer etc. bekommen) und die ein eigenes TreeModel bekommen.
2. diese Bäume sollen aber ein paar gemeinsame Attribute haben, daher benötige ich eine abstrakte Oberklasse. Auch möchte ich hier eine Methode "alle Baumknoten expandieren" implementieren, da ich die mehrfach benötige.
3. die Bäume sollen über ein jeweils typisiertes Interface angesprochen werden, damit ich Zugriff auf die Felder habe.

Wie mache ich das? Baue ich drei Interfaces, die voneinander erben, sowie drei Klassen, die diese implementieren und ihrerseits voneinander erben?

 

[MPW]

Joa offensichtlich scheint das Brett doch nicht so gross zu sein, ich hab dich nicht genau verstanden, aber deine Vorschlaege sehen doch schon ganz gut aus.

Du musst quasi Interfaces nehmen, da die extends ja schon von TreeModel belegt ist, somit sollte das klar sein. Was mir nicht klar ist, warum willst du gleich drei Interfaces haben, eines, was dann von den drei Modellen implementiert wird, sollte doch vollkommen reichen.

 

[SamHotte]

Ne, reicht leider nicht - ich brauche jeweils Zugriff auf die verschiedenen Felder (und möchte nicht immer den Umweg über (Meintyp)getUserObject() gehen müssen), daher habe ich die eigentlichen Daten mit in die Nodes eingebaut. Also ist die vorgesehene Hierarchie:

- Abstrakter Oberknoten (mit Methode zum expandieren des gesamten Baumes, mit getParent(), getChildren() etc.)
- zwei davon erbende Knoten, in denen jeweils die Getter und Setter für die Datenfelder stehen

Wenn ich den Oberknoten weglasse, muss ich jedes der grundlegenden GUI-Elemente (wie z.B. ein JPanel, in dem ein JTree in einem JScrollPane liegt und wo darüber die Anzahl der Knoten angezeigt wird) für jeden dieser Bäume separat bauen; ich hoffe aber, dass ich den nun nur für den Oberknoten machen muss.

Edit: Rechtschreibfehler wech (hoffentlich)

 

[Bleiglanz]

warum machst du nicht

Basis extends TreeModel

A extends Basis
B extends Basis
C extends Basis

 

[SamHotte]

Mach' ich ja. Aber ich möchte jetzt die Dinger auch noch über Interfaces ansprechen, also brauche ich doch für A, B, C auch noch eins, oder?

 

[AlArenal]

Wenn du es so machst, wie Bleiglanz schrieb, sind A, B, C und Basis doch Interfaces....

 

[Bleiglanz]

ist doch ganz egal ob das Interfaces oder Klassen sind?

wenn ich

class Basis extends TreeModel
class A extends Basis

habe, und keinerlei Veranlassung besteht, A weiter zu abstrahieren: warum sollte ich dann

interface IASpezial ...
class A extends Basis implements IASpezial

auch noch einziehen? Damit die Anwendung super-hyper-generisch wird und ich gaaaaaaaaaaanz vieeeeeele Dateien herumwirbeln muss?

Wenn es eh nur ein Dingsbums gibt mit den Eigenschaften von A, dann reicht die Klasse

 

[AlArenal]

Ist ein wenig wie mit der Datenbank-Normalisierung: Wenn mans übertreibt, macht man es sich ganz sicher nicht einfacher...

 

[SamHotte]

Stimmt eigentlich. Ist 'ne Übertreibung des Grundsatzes "gegen Interfaces programmieren", wenn es nur je eine Klasse dazu gibt, richtig? Manchmal denke ich zu kompliziert ... Danke für die Tipps!

 

[AlArenal]

Stimmt eigentlich. Ist 'ne Übertreibung des Grundsatzes "gegen Interfaces programmieren", wenn es nur je eine Klasse dazu gibt, richtig? Manchmal denke ich zu kompliziert ... Danke für die Tipps!

Zumal du ja Eclipse benutzt. Wenn du später mal das Ganze aufbohrst und dann vielleicht Interfaces brauchst, kannste das immernoch über die Refactoring-Funktionen extrahieren und den Sourcecode von Eclipse entsprechend ändern lassen.

 

[SamHotte]

Alles klar - dann räume ich mal die zu vielen Interfaces wieder weg

 

[Bleiglanz]

Stimmt eigentlich. Ist 'ne Übertreibung des Grundsatzes "gegen Interfaces programmieren", wenn es nur je eine Klasse dazu gibt, richtig? Manchmal denke ich zu kompliziert ... Danke für die Tipps!

jep

interfaces haben nämlich auch Nachteile...

 

[MPW]

Wenn du es so machst, wie Bleiglanz schrieb, sind A, B, C und Basis doch Interfaces....

Wohl kaum, da er extends geschrieben hat.

 

[SamHotte]

Sorry, aber: doch. Die extenden nämlich TreeModel, was ein Interface ist ...

Edit: Ups, zu schnell. Da ist natürlich ein fieser Syntaxfehler drin ...

 

[SamHotte]

warum machst du nicht

Basis extends TreeModel

A extends Basis
B extends Basis
C extends Basis

muss eigentlich heißen

interface Basis extends TreeModel

interface A extends Basis
interface B extends Basis
interface C extends Basis

 

[Bleiglanz]

warum nicht?

class Basis extends TreeModel

class A extends Basis
class B extends Basis
class C extends Basis

 

[Roar]

warum nicht?

class Basis extends TreeModel

class A extends Basis
class B extends Basis
class C extends Basis

weil TreeModel ein interface ist, deshalb ging man wohl davon aus, dass Basis auch ein interface sein sollte

 

[Bleiglanz]

genau! mein Hirn!!

ich dachte an

class Basis extends DefaultTreeModel

class A extends Basis
class B extends Basis
class C extends Basis

als "schnellste" Lösung

 

[MPW]

Aso, hab uebersehen, dass TreeModel ein Interface ist;-)

 

[SamHotte]

Ebend ;-)