Moin,
man stelle sich vor, daß ich einen Browser wie Netscape in Java programmieren will. Dazu habe ich mehrere Instanzen von JFrame mit jeweils einer Instanz des Models, die von einem Controller (Singleton) gestartet und gesteuert werden.
Jetzt bin ich mir nicht sicher, wo man die Ereignisse, die in den JFrames auftreten, am besten behandeln sollte.
- In den JFrames selbst kann ich nicht alles behandeln
- Der Controller hat schon genug zu tun, sollte auch eher nicht mit Ereignissen des Views belästigt werden.
- Das Model unter dem JFrame hat ebenfalls nichts mit den Ereignissen zu tun.
Da es hier um meinen Privatspaß geht, würde ich gerne eine saubere Lösung haben, alles was mir einfällt widerspricht entweder Low Cohesion oder High Coupling.
Gibt es ein Muster, das dieses Problem löst?
Thorsten
Hi,
zuerst mal: Ich kenne kein spezielles pattern dafür.
Aber nach dem was ich mir so denke bei einem Browser würde ich versuchen zu filtern nach Eventarten. Denn ich denke mal, das es darstellungsoreintierte gibt (inkl. DHTML - wenn du sowiet bist 
), und mdoellorientierte, die halt vom unterliegenden Controller erledgt werden sollten, zB links mit targets.
Naja, mein 2 Pfennige,
Diez
Moin,
man stelle sich vor, daß ich einen Browser wie Netscape in
ere Instanzen von
JFrame mit jeweils einer Instanz des Models, die von einem
Controller (Singleton) gestartet und gesteuert werden.
Jetzt bin ich mir nicht sicher, wo man die Ereignisse, die in
den JFrames auftreten, am besten behandeln sollte.
- In den JFrames selbst kann ich nicht alles behandeln
- Der Controller hat schon genug zu tun, sollte auch eher
nicht mit Ereignissen des Views belästigt werden.
- Das Model unter dem JFrame hat ebenfalls nichts mit den
Ereignissen zu tun.
Da es hier um meinen Privatspaß geht, würde ich gerne eine
saubere Lösung haben, alles was mir einfällt widerspricht
entweder Low Cohesion oder High Coupling.
Gibt es ein Muster, das dieses Problem löst?
Thorsten
Moin
Aber nach dem was ich mir so denke bei einem Browser würde ich
versuchen zu filtern nach Eventarten.
Mit einem Multicaster? So etwas ähnliches habe ich schon versucht, aber es bleibt die Problematik, zwischen den verschiedenen Events gelichen Typs zu unterscheiden.
Ich versuche es gerade damit, dem ActionCommand etwas mehr mitzugeben und doch jedes Objekt zu einem (potentiellen) Eventsink zu machen. Ma schaun.
Denn ich denke mal, das es darstellungsoreintierte gibt (inkl.
DHTML - wenn du sowiet bist ), und mdoellorientierte, die
halt vom unterliegenden Controller erledgt werden sollten, zB
links mit targets.
Ich will nicht wirklich einen Browser schreiben, sondern ein Hilfsprogramm für ein Spiel. Ehe ich aber jetzt das Spiel erkläre, habe ich Netscape als Beispiel genommen.
Thorsten
Aber nach dem was ich mir so denke bei einem Browser würde ich
versuchen zu filtern nach Eventarten.
Mit einem Multicaster? So etwas ähnliches habe ich schon
versucht, aber es bleibt die Problematik, zwischen den
verschiedenen Events gelichen Typs zu unterscheiden.
Es gibt keine verschiedenen Events gleichen Typs! Wenn es dir um
gutes Design geht, dann ist das wohl der erste Ansatzpunkt.
Lass doch einfach gleich in der Oberfläche verschiedene
Ereignistypen erzeugen oder zumindest auf einem möglichst hohen
Niveau. Die darunter liegenden Schichten haben es dann wesentlich
einfacher, diese auseinanderzuhalten. Außerdem kannst du dadurch
auch eine gewisse Abstraktion der Oberfläche erreichen, wenn
diese nur noch über spezielle Ereignisse mit den unteren
Schichten kommuniziert.
Ich versuche es gerade damit, dem ActionCommand etwas mehr
mitzugeben und doch jedes Objekt zu einem (potentiellen)
Eventsink zu machen. Ma schaun.
Du kannst doch von den vorhandenen Event-Klassen eigene ableiten,
die dem jeweiligen Verwendungszweck am nächsten kommen. Dann sind
sie leicht anhand des Klassentypes unterscheidbar und können
wesentlich besser die jeweiligen Daten aufnehmen.
Stefan 
Moin,
Aber nach dem was ich mir so denke bei einem Browser würde
ich versuchen zu filtern nach Eventarten.
Mit einem Multicaster? So etwas ähnliches habe ich schon
versucht, aber es bleibt die Problematik, zwischen den
verschiedenen Events gelichen Typs zu unterscheiden.
Es gibt keine verschiedenen Events gleichen Typs! Wenn es dir
um gutes Design geht, dann ist das wohl der erste Ansatzpunkt.
Was ich meine sind gleiche Events verschiedenen Ursprungs. Wenn ich zB. ein Fenster schließe, muß der Controller davon informiert werden, um welches Fenster es sich handelt. Im Controller werden die Fenster aber unter dem Namen der Instanz des Models geführt, und ich habe bisher die Möglichkeit übersehen, wie man die dem Event mitgeben kann (setActionCommand()).
Mit dem passenden Actioncommand kann der ActionListener des Frames entscheiden, ob er das Event selbst behandeln kann und der EventHandler des Controllers kann leicht das Ursprungsfenster hearusfinden.
(Wie gibt man eigentlich ein Event weiter, so analog zu throw? Macht das überhaupt Sinn?)
Lass doch einfach gleich in der Oberfläche verschiedene
Ereignistypen erzeugen oder zumindest auf einem möglichst
hohen Niveau.
Du meinst, für jeden Menüpunkt eine eigene Klasse?
Außerdem kannst du dadurch auch eine gewisse Abstraktion der
Oberfläche erreichen, wenn diese nur noch über spezielle
Ereignisse mit den unteren Schichten kommuniziert.
Die Trennung zwischen View/Controller und Model ist ein anderes Problem, weil ich immer einen Frame pro Model habe. Da werden sich noch Probleme ergeben, ich habe da aber noch nicht viel gemacht.
Ich versuche es gerade damit, dem ActionCommand etwas mehr
mitzugeben und doch jedes Objekt zu einem (potentiellen)
Eventsink zu machen. Ma schaun.
Du kannst doch von den vorhandenen Event-Klassen eigene
ableiten, die dem jeweiligen Verwendungszweck am nächsten
kommen. Dann sind sie leicht anhand des Klassentypes
unterscheidbar und können wesentlich besser die jeweiligen
Daten aufnehmen.
Hm. Klingt nach viel Tipparbeit. Ich werde mal sehen, wie weit ich mit den Actioncommands komme und das im Hinterkopf behalten. Vielleicht kann man so GUI-Events von Modelevents trennen.
Danke für die Anregungen!
Thorsten
Ereignismodelle und -verteiler
Wie gibt man eigentlich ein Event weiter, so analog zu throw?
Macht das überhaupt Sinn?
Macht es. Hat aber mit „throw“ soweit nix zu tun.
Normalerweise wirst du irgendwo eine Verteilerklasse benutzen,
die das entsprechende Listener-Interface implementiert un
außerdem selbst Produzent ist, also bei der sich wiederum andere
Listener eintragen können. Dort werden diese dann in einer
Schleife allen eingetragenen Listenern via deren Interface
eingetrichtert. So haben alle was davon…
Du meinst, für jeden Menüpunkt eine eigene Klasse?
Gott bewahre. Eine Menüstruktur sendet doch Kommandoereignisse.
Das ist schon irgendwie das selbe. Da reicht es dann schon i.A.
aus, wenn du einen Ereignistyp verwendest, der einen
Identifikator für das jeweilige ausgewählte Kommande liefert.
Sowas könntest du dann auch weiter verwenden, wenn du mal
vorhaben solltest, die grafische Oberfläche durch sonstewas zu
ersetzen. Die Ereignisse (=Kommandos) bleiben ja die gleichen.
Du kannst doch von den vorhandenen Event-Klassen eigene
ableiten, die dem jeweiligen Verwendungszweck am nächsten
kommen. Dann sind sie leicht anhand des Klassentypes
unterscheidbar und können wesentlich besser die jeweiligen
Daten aufnehmen.
Hm. Klingt nach viel Tipparbeit.
Das hängt davon ab. Solche Klassen sind mittels Vererbung recht
schnell und kurz zu schreiben. Aber du musst natürlich aufpassen,
ob die Ereignisse wirklich einen eigenen Typ bilden (also zB.
bestimmte Datenfelder besitzen, die andere nicht haben). Auch
unabhängige Datenflûsse (zwischen verschiedenen Objekten) sollten
idR. unterschiedliche Ereignisse auslösen. Aber das musst du eben
im Einzelfall entscheiden. Du hast schon Recht, dass das nicht
immer die Dnge vereinfacht. Maßvoll und überlegt eingesetzt kann
es aber sehr positive Auswirkungen auf das Design haben…
Gruß,
Stefan
Moin,
Wie gibt man eigentlich ein Event weiter, so analog zu throw?
Macht das überhaupt Sinn?
Macht es. Hat aber mit „throw“ soweit nix zu tun.
Der Gedanke huschte mir nur gerade durch den Sinn. AWTEventMulticaster habe ich auch schon gefunden, ich weiß aber nicht, welcher Mechanismus da benutzt wird. Reicht es, ein Event zu instanzieren?
Du meinst, für jeden Menüpunkt eine eigene Klasse?
Gott bewahre. Eine Menüstruktur sendet doch
Kommandoereignisse. Das ist schon irgendwie das selbe. Da
reicht es dann schon i.A. aus, wenn du einen Ereignistyp
verwendest, der einen Identifikator für das jeweilige
ausgewählte Kommande liefert.
So will ich erstmal weitermachen: mit ActionEvents und einem hinreichend genauen ActionCommand.
Sowas könntest du dann auch weiter verwenden, wenn du mal
vorhaben solltest, die grafische Oberfläche durch sonstewas zu
ersetzen. Die Ereignisse (=Kommandos) bleiben ja die gleichen.
Ich tummele mich momentan noch bei den Swingbestandteilen, an das Model habe ich mich noch nicht rangetraut.
Thorsten