Muster: Observer

|

Der Beobachter (engl. Observer) dient der losen Kopplung zweier Objekte.

Zweck

Ziel ist es, das beobachtende Objekt über Änderungen im beobachteten Objekt (auch Subjekt genannt) zu informieren. Durch die lose Kopplung ist es möglich, verschiedenste Objekte miteinander zu verbinden. Der Ereignismechanismus (Event) in grafischen Oberflächen basiert auf diesem Prinzip - meist in der Erweiterung des Model-View-Controller-Musters.

UML

Klassendiagramm

Sequenzdiagramm

Entscheidungshilfen

Wenn Instanzen verschiedenster Klassen über Änderungen informiert werden sollen, ist der Beobachter die richtige Wahl.
Von einem Einsatz sollte abgesehen werden, wenn lediglich zwei Instanzen miteinander kommunizieren müssen, da der Overhead für die Implementierung des Beobachter-Musters zu groß wäre.

Implementierung

An der Umsetzung sind mehrere Klassen beteiligt: Beobachter-Interface und seine Erben sowie der Beobachtete (Subjekt). Das Subjekt muss Methoden bereitstellen, über die neue Beobachter registriert oder bereits registrierte Beobachter wieder entfernt werden können. Hinzu kommt eine Methode, die dazu dient, die registrierten Beobachter über Änderungen zu informieren (im UML-Diagram ist diese Methode mit benachrichtigen() bezeichnet). Die Beobachter ihrerseits müssen (mindestens) eine Methode zur Verfügung stellen, über die sie bei Änderungen informiert werden können (im UML-Diagram mit aktualisiere() bezeichnet).

Tritt nun eine Zustandsänderung im beobachteten Objekt auf, muss dessen benachrichtigen()-Methode die aktualisiere()-Methoden aller registrierten Beobachter aufrufen. Diese werden üblicherweise den neuen Zustand des Beobachteten erfragen (subjekt.gibZustand() in obigem UML-Diagram) und entsprechend reagieren, z.B. durch Neuzeichnen einer Oberflächenkomponente in der Model-View-Controller-Architektur.

Neben der vorgestellten Variante gibt es noch eine weitere, die beispielsweise im GUI-Teil der Java-Bibliothek verwendet wird: Bei dieser Variante verfügt die aktualisiere()-Methode des Beobachters noch über einen zusätzlichen Parameter, ein Event-Objekt, das Informationen über den neuen Zustand und üblicherweise auch eine Referenz auf den Urheber der Änderung, also das Subjekt, das den Aufruf der aktualisiere()-Methode veranlasst hat, enthält (letzteres ist wichtig, da ein Beobachter bei dieser Variante bei mehreren beobachteten Objekten registriert werden kann). Anstatt sich den neuen Zustand dann beim Subjekt selbst zu besorgen, kann diese Information aus dem Event-Objekt ausgelesen werden.

Konkrete Implementationen finden sich zu den Programmiersprachen:

Konsequenzen

Abstrakte Kopplung von Subject und Beobachter: z.B. können sie in verschiedenen Schichten der Architektur sein. Wäre dies nicht der Fall dann würde es Kommunikation über Schichten hinweg geben, was das Schichtenprinzip verletzen würde.
Broadcast-Kommunikation wird möglich: Die Benachrichtigung muss den Empfänger nicht kennen.
Unerwartete Updates: Der Beobachter weiß nicht, wie viele weitere Beobachter es gibt, und kann daher auch nicht einschätzen, wie aufwändig eine Statusänderung ist.

Weblinks

Hoch zum Inhaltsverzeichnis