Der Beobachter (englisch Observer) 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 (siehe Viererbande).
Dieses Entwurfsmuster ist auch unter dem Namen publish-subscribe bekannt, frei übersetzt „veröffentlichen und abonnieren“.
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 an- und abzumelden und diese über Änderungen zu informieren. Es kennt alle seine Beobachter nur über die (überschaubare) Schnittstelle Beobachter. Es meldet jede Änderung völlig unspezifisch an jeden angemeldeten Beobachter, braucht also die weitere Struktur dieser Komponenten nicht zu kennen.
Die Beobachter 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 Beobachter 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
Akteure
- Subjekt (Beobachtbares Objekt, auch Publisher, also „Veröffentlicher“, genannt)
- kennt Liste von Beobachtern, aber keine konkreten Beobachter
- bietet Schnittstelle zur An- und Abmeldung von Beobachtern
- bietet Schnittstelle zur Benachrichtigung von Beobachtern über Änderungen
- KonkretesSubjekt (Konkretes, beobachtbares Objekt)
- speichert relevanten Zustand
- benachrichtigt alle Beobachter bei Zustandsänderungen über deren Aktualisierungsschnittstelle
- Schnittstelle zur Erfragung des aktuellen Zustands
- Beobachter (auch Subscriber, also „Abonnent“, genannt)
- definiert Aktualisierungsschnittstelle
- KonkreterBeobachter
- verwaltet Referenz auf ein konkretes Subjekt, dessen Zustand es beobachtet
- speichert dessen Zustand konsistent
- implementiert Aktualisierungsschnittstelle unter Verwendung der Abfrageschnittstelle des konkreten Subjekts
Vorteile
- Subjekte und Beobachter 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 Beobachter zu besitzen, sondern kennt diese nur über die Beobachter-Schnittstelle.
- Ein abhängiges Objekt erhält die Änderungen automatisch.
- Multicasts werden unterstützt.
Nachteile
- Änderungen am Objekt führen bei großer Beobachteranzahl zu hohen Änderungskosten. Einerseits informiert das Subjekt jeden Beobachter, 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 Beobachter 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 Beobachters sichergestellt werden. In einem Multithreading System sind evtl. Lockingmechanismen oder Threads mit queuing zur Beobachter-Notifizierung erforderlich.
Beispiele
Implementierung in C++
Diese Implementierung erlaubt es nicht, während einer Benachrichtigung (Notification) im gleichen Thread einen Observer zu entfernen, weil dadurch die Iteratoren ungültig würden. Eine Möglichkeit zum Lösen dieses Problems ist, „abgehängte“ (detached) Observer in einer eigenen Liste zu verwalten und nicht direkt aus der Observer-Liste zu entfernen. Dann wirkt sich das Entfernen erst bei einer erneuten Benachrichtigung aus. Dabei müsste in der Benachrichtigungsschleife geprüft werden, ob der Observer nicht bereits detached wurde.
class CObserver
{
public:
virtual void NotifyStateChange( void ) = 0 ;
} ;
class CObserverSubject
{
private:
typedef CObserver tObserver ;
typedef std::deque< tObserver* > tOBSERVERS ;
tOBSERVERS Observers ;
public:
bool AddObserver( tObserver* Observer )
{
tOBSERVERS::const_iterator foundObserver =
std::find( this->Observers.begin(), this->Observers.end(), Observer ) ;
if( foundObserver == this->Observers.end() )
{
this->Observers.push_back( Observer ) ;
return true ;
}
else
{
return false ;
}
}
bool RemoveObserver( tObserver* Observer )
{
tOBSERVERS::iterator foundObserver =
std::find( this->Observers.begin(), this->Observers.end(), Observers ) ;
if( foundObserver != this->Observers.end() )
{
this->Observers.erase( foundObserver ) ;
return true ;
}
else
{
return false ;
}
}
void NotifyStateChange()
{
tOBSERVERS::const_iterator allObservers = this->Observers.begin() ;
while( allObservers != this->Observers.end() )
{
( *allObservers )->NotifyStateChange() ;
allObservers++;
}
}
} ;
Weiteres Beispiel in C++
#include <list>
#include <string>
#include <iostream>
#include <sstream>
#include <algorithm>
/************************** Subjekt und Beobachter ***********************************/
class Subject;
struct Observer
{
virtual void update( Subject* ) = 0;
};
class Subject
{
public:
void attach( Observer* );
void detach( Observer* );
void notify();
private:
std::list<Observer*> observers_;
};
void Subject::attach( Observer* o ) //MeldeAn
{
observers_.push_back(o);
}
void Subject::detach( Observer* o ) //MeldeAb
{
observers_.erase(
std::remove_if(observers_.begin(), observers_.end(), std::bind2nd(std::equal_to<Observer *>(), o)),
observers_.end());
}
void Subject::notify() //Benachrichtige
{
std::for_each(observers_.begin(), observers_.end(), std::bind2nd(std::mem_fun(&Observer::update), this));
}
/************************** Konkretes Subjekt ***********************************/
class MailServer : public Subject
{
public:
MailServer( std::string name ): name_(name){}
void neuerNewsletter() { notify(); }
std::string getName() const {return name_;}
private:
const std::string name_;
};
/************************** Konkreter Beobachter ***********************************/
class EmailKonto: public Observer
{
public:
EmailKonto( std::string name, MailServer* );
~EmailKonto();
void update( Subject* );
std::string getName() const {return name_;}
MailServer* getSubject() const {return subject_;}
private:
const std::string name_;
MailServer* subject_;
};
EmailKonto::EmailKonto( std::string name, MailServer* s ) : name_(name), subject_(s)
{
subject_->attach(this);
}
EmailKonto::~EmailKonto () { subject_->detach(this); }
void EmailKonto::update( Subject* s ) //Aktualisiere
{
if( s == subject_ )
std::cout << "Hallo Herr Nr. " << getName() << ", ein neuer Newsletter von "
<< subject_->getName()<< " ist erschienen." << std::endl;
}
/************************** Hauptprogramm ***********************************/
int main()
{
MailServer s("HenkesSoft3000"); //Subjekt "MailServer"
const int N = 5;
EmailKonto** pMK = new EmailKonto*[N];
for(int i=0; i<N; ++i)
{
std::ostringstream n;
n << i;
pMK[i] = new EmailKonto(n.str(), &s); //Mailkonten melden sich an
}
s.neuerNewsletter();
for(int i=0; i<(N-2); ++i)
{
pMK[i]->getSubject()->detach(pMK[i]); //Zwei Mailkonten melden sich ab
}
s.neuerNewsletter();
delete [] pMK;
}
Observierung in Objective-C und Cocoa
Das Entwurfsmuster ist bereits als Kategorie von NSObject implementiert, so dass seitens des Observierten kein Aufwand anfällt. Der Observierer muss sich lediglich anmelden und eine Notifizierungsmethode implementieren:
// Anmeldung der Observierung [theObserved addObserver:self forKeyPath:@"attribute" options:NSKeyValueObservingOptionNew context:'WIKI'];
// Abarbeitung - (void)observeValueForKeyPath:(NSString*)keyPath ofObject:(id)object change:(NSDictionary*)change context:(void*)context
Dabei ist zu beachten, dass im Gegensatz zum obigen Code in C++ die Oberservierung für ein bestimmtes Attribut erfolgt, also wesentlich weniger Kosten verursacht. Die Auslösung der Observierung muss zudem nicht manuell erfolgen, sondern wird vom System transparent erledigt, sobald ein Setter für das entsprechende Attribut aufgerufen wird. Daher führt jede Änderung automatisch zur Notifizierung:
// Irgendwo in den Untiefen des Codes [anObject setAttribute:@"some data"]; // Die Observierung von attrbute wird ausgelöst
Hierzu wird eine Technologie namens isa-Swizzling angewendet.
Listener und Events in Java
Java bietet fertige Observer und Observableklassen an, die der Entwickler verwenden kann.
Die Nachteile des Entwurfsmusters entfernt Java, indem es das Beobachterkonzept durch Listener und Events ersetzt. Interessiert sich eine Klasse für eine andere, implementiert sie deren Listener-Interface und meldet sich beim Subjekt an. Ändert sich das Subjekt, informiert es seine Beobachter durch den Aufruf der Listenerschnittstelle, die die Änderung beschreibt.
Verwandte Entwurfsmuster
- Ein Vermittler kann zwischen Subjekten und Beobachtern vermitteln.
