Wann verwendet man PropertyChangedEvents, wann eigene?

[Marco13]

Hi

Gibt es irgendwelche "best practices", wie man das Event-Handling von "vielen" Modellen und Eigenschaften am günstigsten implementiert?

PropertyChangeEvents sind mir irgendwie suspekt: Einerseits sind sie sehr praktisch (und so allgemein, dass es schon nichtmehr allgemeiner geht), aber andererseits sind sie ja eigentlich nur für Java Beans gedacht, und durch die "Object" als values so wenig typsicher und durch die String-identifier so Fehleranfällig (etwa, wenn Members umbenannt werden) dass ich nicht sicher bin, ob man sie in eigenen Modellen überhaupt verwenden sollte... ???:L
Anders formuliert: Man könnte ja theoretisch(!) ALLE Events als "PropertyChangeEvent" implementieren (Selbst bei MouseEvents wird ja nur die "Property" der Mausposition geändert - nur zur Verdeutlichung... :roll: ), und es muss ja einen Grund geben, warum das nicht gemacht wird...

Wenn man aber viele Modellklassen und viele Eigenschaften hat, erscheint mir das Erstellen von dedizierten Listener-Interfaces mit 5, 10 oder mehr Methoden und das Erstellen, Feuern und Behandeln der dazugehörigen Events so repititiv und redundant (und beim Implementieren so verdammt langweilig :roll: ), dass ich mir kaum vorstellen kann, dass es da nicht eine bessere Lösung gibt...

Sicher kann man sich da einige Ansätze überlegen, aber irgendwie hat man wohl immer diesen "Tradeoff" zwischen der Typsicherheit und dedizierten, eindeutigen Methoden bei einzelnen Listenern, und einem einfachen, allgemeinen, aber auch etwas "schwammigen" Konzept mit allgemeinen Events und irgendwelchen String-Identifiern für die geänderten Eigenschaften.

Mich würde interessieren, wie ihr die verschiedenen Ansätze einschätzt, ob ihr vielleicht einen "goldenen Mittelweg" kennt, oder wo ihr Vor- oder Nachteile seht, die ich noch nicht bedacht habe.

bye

 

[Niki]

Naja, ich hab einmal versucht ein Projekt wirklich schön strukturiert zu verwirklichen und hab zwischen den Komponenten (Controller und View) nur mittels PropertyChangeEvents kommuniziert. Ich wollte das damals einfach mal ausprobieren, jedoch finde ich es bei einer so engen Verbindung unnötig. Es macht den Code unleserlich und es ist schwer nachzuvollziehen was passiert.
Wenn du eine Bean implementierst, die Eigenschaften hat welche sich ändern können kannst du das schon mit einem PropertyChangeListener realisieren. Ansonsten bietet sich ja auch manchmal das Observer Pattern an.
Bei engen Verbindungen zwischen Klassen würde ich direkt auf Method-Calls arbeiten (wie eben bei View und Controller, nur das Model sollte natürlich komplett losgelöst implementiert sein)

 

[inflamer]

Moin!

Also, die Eigenschaften/String-Identifier oder wie auch immer man sie nennen mag, kann man ja in Konstanten "festhalten". Das Problem fällt also schon mal weg.

Des weiteren wird von dem PropertyChangeListener trotz seiner Residenz im java.beans-Package auch in der Swing-API regen Gebrauch gemacht. (s. http://java.sun.com/javase/6/docs/api/java/beans/PropertyChangeListener.html - All Known Implementing Classes)

Auch ein Vorteil: Leitet man eine Klasse ab, die bereits ein Listener ist, kann man sich die add/removeListener()-methoden sowie eine EventListenerList u.U. sparen.

Nachteil ist IMHO einzig die Typunsicherheit bzw. die Notwendigkeit des Castens.

Sinnvoll einen weiteren (eigenen?) Listener zu verwenden erscheint mir aber dann, wenn bestimmte Events aus konzeptioneller Sicht nicht jeden Listener etwas angehen, sprich nicht alle aufkommenden Events an sämtliche Listener verschickt werden sollen (Stichwörter: Kapselung, Performance).

(Kein Anspruch auf Vollständigkeit und Objektivität. ;-) )

 

[Marco13]

OK, die Alternativen wie Observer sind mir prinzipiell bekannt, aber eigentlich ist das Observer-Pattern auch nur ein Event-Listener-Pattern, wo der geworfene Event eben "void" ist :wink:

Hmja, dass man die String-IDs nicht 100x per Hand in den Code hacken würde, ist klar, so gesehen ist das vielleicht nichtmal das größte Problem (anstelle eines Strings denke ich jetzt an einen enum, was von der Verwendung her ziemlich ähnlich ist, aber noch einen Hauch mehr Typsicherheit bietet).

Unschön finde ich bei einer "allgemeinen" Listener-Klasse (wie PropertyChangeListener), dass der Code ziemlich verwirrend und mehrdeutig werden kann, wenn man einen Listener zu ZWEI (oder mehr) anderen Klassen addet, und dort dann mit "if (event.getSource() == ...)" rumhantieren muss... :? Aber vermutlich ist das der Preis, den man zahlt, wenn man nicht 100x Code schreiben will, der zwar jedesmal "strukturell gleich" ist, aber sich immer in einem Klassen/Methodennamen unterscheidet :?