Swing Actions Designfrage

[Zenic]

Hi,

ich schreibe gerade zum ersten mal ein etwas größeres Interface, bei dem Aktionen an mehreren Stellen der GUI ausgeführt werden können. (Menü, Toolbar, ...) Anstatt wie bisher direkt einen anonymen Actionenlistener zu implementieren, verwende ich nun Actions.

Nun soll nach Betätigung des Buttons ein bestehendes JPanel (parentPanel) der GUI mit einem anderen überschrieben werden. Das Problem ist jedoch, dass die Action das parentPanel nicht kennt, als Lösung dachte ich, ich übergebe der Action einfach dieses Panel, welches jedoch weder dem Menü noch der Toolbar bekannt ist.

Wie löst man das am elegantesten? Soll das Panel durchgereicht werden oder vielleicht sogar statisch erreichbar gemacht werden? Sind Actions überhaupt die richtige Wahl?

danke
Zenic

 

[SlaterB]

mit Actions an sich hat das nichts zu tun, auch mit ActionListener musst du dich genauso darum kümmern,
was wo bekannt ist, was wo definiert wird

ob statisch oder durchgereicht bzw. allgemeine Fragen zu Sichtbarkeit haben ebenso mit deinem GUI-Thema nicht besonders viel zu tun,
das ist allgemein immer eine Abwägung,
wobei GUI-Komponten wie einzelne JPanel mit bestimmten Inhalt (oft gar als eigene Klasse) recht typische Kandiaten für nur einmal erzeugte Objekte sind, da ist das Ablegen in einer statischen Variable vertretbarer als in anderen Fällen

allgemein gilt: fange ruhig mit static an, sobald du Probleme damit feststellst, wirst du auf natürliche Weise zum Umschwenken gezogen,
der Lehre nach ist static nicht gut, meist aber aus für Anfänger-Belange relativ abgehobenen Gründen wie strukturierte Testbarkeit

 

[slawaweis]

gerade bei Swing sollte man static auf alle Fälle vermeiden, um ein flexibles System zu haben.

In diesem Fall fehlt noch eine Abstraktionsschicht. Action aus Swing ist eine Abstraktion eines GUI-Ereignisses, das unter anderem durch den User ausgelöst wird. Das, was danach das eigene Programm macht, muss nicht in der Action drin sein. Am besten wäre es eine Art Manager für Funktionalität zu haben, Beispiel:

public interface IMyUIManager
{
 public void operationA();
 public void operationB();
 public void operationC();
}

diesen Manager übergibt man an die Action. Wenn die Action ausgelöst wird, ruft sie die entsprechende Methode in IMyUIManager auf. Was darin passiert, ist der Implementierung des IMyUIManager überlassen. Der Vorteil von dieser zusätzlichen Abstraktionsschicht wäre, dass nur darin die Logik bekannt sein müsste und man es z.B. für Tests ohne eine Action aufrufen könnte. Es geht noch abstrakter:

public interface IMyUIManager
{
 public void operation(String name);
}

damit kann man über bestimmte Namen bestimmte Operationen anstoßen. Diese können auch gar nicht implementiert oder wieder verworfen sein, was der IMyUIManager mit einer entsprechenden Fehlermeldung behandelt. So bleibt die Logik an einem Ort.

Slawa