Observer (Entwurfsmuster)

Der Observer (Beobachter, Listener) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Verhaltensmuster (Behavioural Patterns). Es dient zur Weitergabe von Änderungen an einem Objekt an von diesem Objekt abhängige Strukturen. Das Muster ist eines der sogenannten GoF-Muster (Gang of Four; siehe Viererbande).

Dieses Entwurfsmuster ist auch unter dem Namen publish-subscribe bekannt, frei übersetzt „veröffentlichen und abonnieren“.

Neben publish-subscribe erfährt das Beobachter-Muster mit dem Signal-Slot-Konzept eine weitere Ausprägung.

Verwendung

Anwendungsbeispiel

Eine oder auch mehrere Komponenten stellen den Zustand eines Objektes grafisch dar. Sie kennen die gesamte Schnittstelle dieses Objektes. Ändert sich der Zustand des Objektes, müssen die Komponenten darüber informiert werden. Andererseits soll das Objekt aber von den Komponenten unabhängig bleiben - ihre Schnittstelle also nicht kennen.

Beispiel: Messergebnisse werden gleichzeitig in einem Balkendiagramm, einem Liniendiagramm und einer Tabelle dargestellt. Messwerte ändern sich permanent. Die Komponenten der Diagramme sollen diese Änderungen permanent darstellen, das gemessene Objekt soll dabei aber keine Kenntnis über die Struktur dieser Komponenten besitzen.

Lösung

Das beobachtete Objekt bietet einen Mechanismus, um Beobachter (Observer) an- und abzumelden und diese über Änderungen zu informieren. Es kennt alle seine Observer nur über die (überschaubare) Schnittstelle Observer. Es meldet jede Änderung völlig unspezifisch an jeden angemeldeten Observer, braucht also die weitere Struktur dieser Komponenten nicht zu kennen.

Die Observer implementieren ihrerseits eine (spezifische) Methode, um auf die Änderung zu reagieren. In der Regel werden die für eine Komponente relevanten Teile des Zustands abgefragt.

Allgemeine Anwendungssituationen

Allgemein finden Observer Anwendung, wenn eine Abstraktion mehrere Aspekte hat, die von einem anderen Aspekt derselben Abstraktion abhängen, die Änderung eines Objekts Änderungen an anderen Objekten nach sich zieht oder ein Objekt andere Objekte benachrichtigen soll, ohne diese im Detail zu kennen.

UML-Diagramm

Klassendiagramm, das die am Entwurfsmuster beteiligten Rollen zeigt.

Das folgende Klassendiagramm zeigt die am Entwurfsmuster beteiligten Rollen. Das Subjekt kann mehrere Beobachter haben, die unterschiedlichen konkreten Klassen angehören können.

Akteure

Ein Subjekt (Beobachtbares Objekt, auch Publisher, also „Veröffentlicher“, genannt) kennt eine Liste von Observern, aber keine konkreten Observer. Es bietet eine Schnittstelle zur An- und Abmeldung von Observern und eine Schnittstelle zur Benachrichtigung von Observern über Änderungen an. Ein Konkretes Subjekt (Konkretes, beobachtbares Objekt) speichert den relevanten Zustand und benachrichtigt alle Observer bei Zustandsänderungen über deren Aktualisierungsschnittstelle. Es verfügt über eine Schnittstelle zur Erfragung des aktuellen Zustands.

Die Beobachter (Observer auch Subscriber, also „Abonnent“, genannt) definieren eine Aktualisierungsschnittstelle. KonkreteBeobachter verwalten die Referenz auf ein konkretes Subjekt, dessen Zustand sie beobachten und speichern dessen Zustand konsistent. Sie implementieren eine Aktualisierungsschnittstelle unter Verwendung der Abfrageschnittstelle des konkreten Subjekts.

Vorteile

Subjekte und Observer können unabhängig variiert werden. Subjekt und Benutzer sind auf abstrakte und minimale Art lose gekoppelt. Das beobachtete Objekt braucht keine Kenntnis über die Struktur seiner Observer zu besitzen, sondern kennt diese nur über die Observer-Schnittstelle. Ein abhängiges Objekt erhält die Änderungen automatisch. Multicasts werden unterstützt.

Nachteile

Änderungen am Objekt führen bei großer Observeranzahl zu hohen Änderungskosten. Einerseits informiert das Subjekt jeden Observer, auch wenn dieser die Änderungsinformation nicht benötigt. Zusätzlich können die Änderungen weitere Änderungen nach sich ziehen und so einen unerwartet hohen Aufwand haben.

Ruft ein Observer während der Bearbeitung einer gemeldeten Änderung wiederum Änderungsmethoden des Subjektes auf, kann es zu Endlosschleifen kommen.

Der Mechanismus liefert keine Information darüber, was sich geändert hat. Die daraus resultierende Unabhängigkeit der Komponenten kann sich allerdings auch als Vorteil herausstellen.

Bei der gerade durchgeführten Observierung eines Objektzustands kann es notwendig sein, einen konsistenten Subjektzustand zu garantieren. Dies kann durch synchrone Aufrufe der Notifizierungsmethode des Observers sichergestellt werden. In einem Multithreading System sind evtl. Lockingmechanismen oder Threads mit queuing zur Observer-Notifizierung erforderlich.

Verwandte Entwurfsmuster

Ein Vermittler kann zwischen Subjekten und Observern vermitteln.

Siehe auch

 Wikibooks: Muster: Observer – Lern- und Lehrmaterialien

Entwurfsmuster der Viererbande

Erzeugungsmuster:  Abstrakte Fabrik | Singleton | Builder | Fabrikmethode | Prototyp

Strukturmuster:  Adapter | Brücke | Decorator | Fassade | Flyweight | Kompositum | Stellvertreter

Verhaltensmuster:  Observer | Visitor | Interpreter | Iterator | Kommando | Memento | Schablonenmethode | Strategie | Vermittler | Zustand | Zuständigkeitskette

(Klassenmuster sind kursiv dargestellt)