Swing Komponenten organisieren

[TheWhiteShadow]

Hallo,

Ich schreibe eine größere Swing-Anwendung und habe bei den Komponenten ein immer wiederkerendes Problem.
Eine Komponente muss Grafikelemente einer anderen Komponente manipulieren.

Bisher kennt nur das JFrame die relevanten Komponenten und übergibt die benötigten Komponenten in den Konsturkoren seiner Kind-Elemente.
Das ging anfangs noch ganz gut, aber je mehr Funktionen die Komponenten bekommen, desto mehr Quer-Referenzen benötigen sie.
Die Reihenfolge der Komponenten ist schon stark fixiert und ich vermeide nur mühevoll Zirkelreferenzen.

Kann man das irgendwie allgemeiner lösen?

Ein weiteres Problem ist die Komplexität dieser Querreferenzierung, da das eigentliche Model, was die relevanten Daten enthält kaum Änderungen unterliegt, die Verwaltung des Grafikinterfaces aber bald aus allen Nähten platzt.
Lohnt sich dazu ein eigenes Modelkonzept für das Grafikinterface. Und wenn ja, wie baut man so etwas auf?

mfg TWS

 

[Tomate_Salat]

Um die Referenzen aufzulösen setzt man ein DI-Framework (z.B. google-Guice) ein. Dieses Framework kümmert sich dann um deine Abhängigkeiten, die du dir nach Bedarf einfach Injecten lassen kannst.

 

[TheWhiteShadow]

Bei DI wird ein Objekt in ein anderes Objekt als referenz gesetzt, wenn dieses erstellt wird.
Das löst irgendwie die Abhängigkeit der Reihenfolge überhaupt nicht.

Mein letzter Ansatz war eine Auslagerung der Komponenten in eine statisches Speicherklasse.
Auf diese Weise hätte ich immer Zugriff auf alle Komponenten, und muss die Konstruktions-Reihenfolge nicht mehr beachten, aber ich will kein Statisches Objekt haben.

Das 2. Problem versuche ich grade mit intensivem Gebrauch des Observer-Pattern zu lösen.
Bisher kamen nur viele Klassen hinzu, übersichtlicher als vorher ist es noch nicht.

 

[bERt0r]

Dann mach dir in deinem JFrame doch eine Map, in der du dir sämtliche Komponenten mit einem eindeutigen Schlüssel speichers. Den Komponenten übergibst du eine Referenz auf die Map, und wenn sie Zugriff auf einen anderen brauchen, suchen sie ihn sich mithilfe des Schlüssels.

z.B Map<String,JComponent> components....
components.add("MainPanel",panel1);
components.add("ImageLabel",imgLabel1);

 

[vanny]

Ergänzend zu bERt0r noch eine kleine Grafik, die dir vielleicht hilft.

Gruß Vanny

 

[TheWhiteShadow]

Ich hab mein statische Objekt in soweit abgeändert, dass es als Schnittstelle für Plugins fungiert. Es ist nicht mehr statisch und erlaubt Listener zu adden. Dadurch benötige ich keinen weiteren externen Zugriff.

Eine Map klingt dennoch gar nicht schlecht, zumal es nicht auf einen festen Satz an Komponentne limitiert und somit auch für plugins praktisch ist. Und da Listener unbekannten Typs schwer zu verwalten sind, kommt es bei Plugins eigentlich ganz gut, dessen GUI-Elemente Global über eine Map verfügbar zu machen.

Edit:
@vanny
aus der Grafik werd ich patu nicht schlau.

 

[vanny]

ok dann vielleicht 2-3 Worte dazu.

1. Klasse: WidgetCreator:
Der WidgetCreator erzeugt und hält alle benötigten Komponenten zBsp. in einer Map.
Dann packst du die benötigten Komponenten in deinen Frame ">>add();>>".
eigntl. benötigst du nur einen Getter, der dir anhand des Keys die passende Komponente zurückgibt.
evt. noch hier und da ´ne setMethode();.

2. Klasse: DivListener:

steht halt sysmbolisch für all deine Listener, die du so benötigst.
Denen übergibst du ne Referenz vom WidgetCreator und besorgst dir dort dann die Referenzen für deine Änderungen, nimmst diese vor und gibst dem WidgetCreator nochmal bescheid, dass der Frame mal neu gezeichnet werden soll.

3. Klasse ist halt dein Frame:

nc

//EDIT:
Dadurch hast du keine Statischen Objekte und kannst im Listener flexibel auf die verschiedenen Komponenten zugreifen.

Gruß Vanny

 

[TheWhiteShadow]

Was genau bezeichnest du in deinem Model als "Änderung"
Die Änderung, dessen Information den Listenern mitgeteilt wird, oder die Reaktion der implementierenden Komponente?

Dein "WidgetCreator"-Model brauch ich nicht in der Form, da ich bei den Listenern immer nur die Komponente brauch, welche das Event ausgelöst hat, und die schickt ich gleich mit.
Ich zeichne auch immer nur die Kompnente neu, die sich geändert hat. Wenn sich mehrere Komponenten ändern, läuft der repaint mit über die Listener.

Einzige Ausnahme bildet das Menü, da es weniger Reaktionen hervorruft, als viel mehr Verhaltensweisen der Komponenten ändert.
Da ich dessen Konfiguration aber bereits in einigen Konstuktoren benötige, hab ich es gleich mitgegeben.

 

[vanny]

Hehe,
bevor wir aneinander vorbei reden, ich benutze allgemeine Begriffe wie Änderungen, weil ich nicht weiß, was du da wirklich baust.

Ich wollte dir lediglich eine Idee unterbreiten, wie du flexibel auf deine Komponenten zugreifen kannst, ohne statisch zu werden und, wie du es bezeichnet hast Querreferenzierungen zu bekommen.

Was genau bezeichnest du in deinem Model als "Änderung"
Die Änderung, dessen Information den Listenern mitgeteilt wird, oder die Reaktion der implementierenden Komponente?

Eigentlich die Änderung die der Listener auf der/den fremden Komponente(n) auslöst.
Naja scheint so, als wüßtest du mittlerweile besser was du da vorhast also lass dich durch mich einfach nicht verwirren

Gruß Vanny

 

[TheWhiteShadow]

Ok, ich war mir da nicht so sicher.^^

Dein Model behalte ich mal im Hinterkopf. Jenachdem was da noch hinzukommt, könnte es doch noch in irgendeiner Form relevant werden.