Objektorientierte Entwurfsmuster - Architektur und Entwurfsmuster der Softwaretechnik - page 168

Objekt dar. Dies führt wiederum zu einer Schachtelung der Methodenaufrufe und zu ei-
ner neuen verschobenen Ausführungsspezifikation.

Das folgende Sequenzdiagramm zeigt exemplarisch die Anmeldung und Aktualisie-
rung eines Beobachters:

:Beobachtbar

:Beobachter

anmelden (this)

anmelden()

setzeZustand()

ben achrichtigen()

aktualisieren (this)

aktualisieren ()

gibZustand()

gibZustand() : zustand

Bild 4-35 Sequenzdiagramm für die Anmeldung und Aktualisierung eines Beobachters

4.11.3.4 Lösungsvariante mit dem Push-Verfahren

Die bisher beschriebene Pull-Variante ist dadurch charakterisiert, dass ein Beobachter
zwar über eine Zustandsänderung informiert wird (Methode aktualisieren() ), er
aber danach sich die Informationen über den neuen Zustand beim beobachteten Ob-
jekt abholen muss (Methode gibZustand() ).

In der Push-Variante werden die beiden genannten Methoden praktisch zu einer einzi-
gen zusammengeführt: die Methode aktualisieren() erhält zusätzlich einen oder
mehrere Parameter, die den neuen Zustand des Beobachtbaren beschreiben 59 . Durch
einen Aufruf dieser modifizierten Methode aktualisieren() beim Beobachter
"drückt" (push) das beobachtete Objekt gleich alle Informationen zu dem Beobachter
hin. Die Methode gibZustand() kann entfallen.

Der Vorteil des Push-Verfahrens liegt damit auf der Hand: der Rückruf des Beob-
achters, um sich Informationen zu beschaffen, entfällt. Häufig sind im Pull-Verfahren
für diese Informationsbeschaffung sogar mehrere Methodenaufrufe nötig - je nachdem
wie die Schnittstelle vom Beobachtbaren konzipiert ist - die alle im Push-Verfahren
überflüssig werden.

Ein Vorteil des Pull-Verfahrens ist darin zu sehen, dass die Schnittstelle zum Abholen
der Information "breit" gemacht werden kann: Statt der bisher genannten Methode

59 Damit verringert sich die Wiederverwendbarkeit der Methode aktualisieren() deutlich.