Dieses mal ein etwas ausführlicher Blog zum Thema meines Vortrages bei bonn-to-code. Meine viel zu kurzen 20 Minuten hatten eine volle Agenda mit verschiedenen Varianten des Observer Pattern bis hin zu einem Message Dispatcher ;) . Log geht’s!

 

Events statt Attach/Detach

Das Observer Pattern nach GOF war den meisten (oder allen) Zuhörern bereits bekannt, also konnte direkt mit der ersten .NET Modifikation begonnen werden. Die Logik des Attach und Detach von Beobachtern lässt sich wunderbar durch Events und EventHandler ersetzen. Events implementieren genau diese Funktionalität: Eine Liste von Funktionen zu verwalten und letztlich diese aufzurufen. Durch diesen Umbau ist der Code deutlich schlanker geworden und der Verwaltungscode wurde aus dem Subjekt entfernt.

Statusänderungen im größeren Kontext

Das Observer Pattern bietet eine sehr gute Möglichkeit, Statusänderungen an betroffene Ansichten durchzureichen. Dabei wird das Hollywood Prinzip (“Don’t call us, we call you”) beachtet, nachdem das Subjekt die Beobachter informiert und nicht die Beobachter regenmäßig das Subjekt überprüfen. Ein Problem entsteht, wenn mehrere Subjekte zu unterschiedlichen Zeitpunkten angezeigt werden sollen. Ein gutes Beispiel ist eine Liste aus Subjekten mit verschiedenen Vorschau-Ansichten. Nun wird es schwierig, das neue Subjekt an die unbekannte Anzahl an Ansichten zu senden.

Die Lösung hierfür ist ein SubjectNotifier mit statischen Events zum Verteilen von Nachrichten an alle Beobachter. Jeder Beobachter kann mittels SubjectStateChanged eine auf Statusänderung und mittels SubjectSelected auf eine Subjektänderung reagieren. Über die Raise* Methoden können beliebige Ansichten die entsprechenden Event auslösen, falls sich der Status oder das Subjekt geändert hat.

Fazit

Diese Variante, Statusänderungen eines Subjekts über einen SubjectNotifier zu publizieren, hat mehrere Vorteile. Alle Subjekte (auch neue Instanzen) können über einen zentralen Dispatcher publiziert werden. Es erweitert das Hollywood Prinzip aus dem klassischen Observer Pattern insoweit, dass nicht nur der Beobachter mit DEM Subjekt verbunden ist, sondern das der Beobachter noch nicht einmal das Subjekt kennt sondern von irgendwelchen Subjekten benachrichtigt wird. Ein weiterer Vorteil ist, dass das Subjekt absolut keine Logik zum Verteilen und Verwalten von Statusänderungen enthält. Das Subjekt ist unabhängig von interner Verwaltungslogik die nur einzelne Applikationen betrifft und z.B. in Konsolenanwendung nicht benötigt wird.

… dieses war der erste Streich, doch der zweite folgt sogleich!