Hallo,
Ich habe meist das Problem, dass es mehrere Komponenten gibt
und die meisten horchen auch auf Eingaben. Ich bin eher der
Fan von einem Manager der die Steuerung übernimmt und die
Komponenten nur für die Visualisierung da sind.
Soll ja auch so sein.
Zum Beispiel - in der Toolbar COPY und im Menü COPY - wäre
doch schlecht wenn jedes in einer eigenen Prozedur darauf
reagiert.
Wieso eigene Prozeduren? Dann hast du ja Redundanz drin, was nicht gut ist. Wenn die beiden Dinge das gleiche tun, dann soll auch eine Methode deren Aufgabe machen.
Jetzt mach ich zB. im Manager Kopieren was von
beiden aufgerufen wird. Das Problem was ich immer damit habe
bzw. nicht mag ist, dass ewige weiterreichen, zB. wenn man
verschachtelte Komponenten hat, dann muss zB ein Panel ohne
Listener auch den Manager besitzen, wenn die Panelkinder auf
etwas reagieren.
Das ist zwar richtig, aber das irgendwie müssen die Events ja weitergereicht werden, wenn du sie nicht gleich an Ort und Stelle bearbeiten willst. Es gibt zwar schon einige Lösungen, die aber nur mehr oder weniger schön sind.
So kannst du z.B. wenn du nur einen einzigen Manager in deiner Anwendung brauchst, diesen so machen, das er über eine statische Methode erreichbar ist. Dann sparst du dir das Weiterreichen, handelst dir aber - falls es vorkommen kann, das gleichzeitig zwei Dinge im Manager passieren - Synchronisationsprobleme ein. Schaut dann ungefähr so aus:
public class Manager {
// Hier wird die einzige Instanz gespeichert
private static Manager INSTANCE = null;
/\*\*
\* Mit dieser Methode holst du dir eine Instanz des Managers
\*\*/
public static Manager getInstance() {
if (INSTANCE == null) {
INSTANCE = new Manager();
}
return INSTANCE;
}
/\*\*
\* Der Konstruktor des Managers ist private, damit man nur getInstance()
\* benutzen kann, um eine Instanz zu bekommen.
\*\*/
private Manager() {
}
}
Gibt es da ein gutes Entwurfsmuster? Tipps?
Naja, du könntest Basisklassen für deine Frames, Panels und Buttons machen, die von den Original-Java-Klassen abgeleitet sind. Diese könnten dann z.B. Methoden zum weiterreichen und speichern des Managers besitzen, die im Konstruktor ausgeführt werden (bei abgeleiteten Sachen den super() Aufruf nicht vergessen. Damit lässt sich das Weiterreichen relativ gut automatisieren.
Auch könntest du statt einem selbst gebauten Manager auch gleich Observer benutzen, wobei der Aufbau der Observer-Observable-Verknüpfungen auch automatisch passieren könnte, in dem du erstmal Basisklassen schaffst.
mfg
deconstruct