Observer Pattern – Patterns II

Einleitung

Herzlich Willkommen zurück zu meiner Serie über Design Pattern bzw. auf deutsch Entwurfsmuster. Im letzten Teil habe ich dir das Strategy Pattern näher gebracht, mit dem du Verhalten kapseln und wiederverwenden kann. Heute will ich dir das nächste Pattern erklären: das Observer Pattern.

Stell dir vor du arbeitest für eine Software Entwicklungsfirma und dein Team soll eine Software entwickeln die Unternehmenskritische, statistische Daten darstellen soll. Die Daten sind von mehreren Orten zu sammeln und bei neu eintreffenden Daten sind die Clients der Geschäftsführung zu aktualisieren. Es soll nur eine tabellarische Ansicht besitzen.

Deine Kollegen und du ihr denkt darüber nach und entschließt euch für ein Design bei dem ihr eine Klasse habt, die die Daten zusammen sammelt und zur Verfügung stellt. Die Grafische Oberfläche soll die Daten mittels Getter-Methoden direkt aus dieser Klasse ziehen.

Tabellarische Ansicht holt Daten vom Datensammler

Ihr wollt euch gerade an die Implementierung machen, da kommt dein Chef und findet die Idee super eine weitere Ansicht mit grafischen Diagrammen zu erstellen.

Ihr hattet euch gefreut das Design abgeschlossen zu haben und nun das. Erneut setzt Ihr euch an das Design und überlegt wie Ihr diese Ansicht implementieren könnt. Sie könnte doch auch die Daten immer wieder aus der zentralen Klasse ziehen.

Tabellarische & Diagrammansicht holen Daten vom Datensammler

Du hörst nur halb zu denn dein Hirn läuft auf Hochtouren. Du merkst das dir etwas an diesem Entwurf nicht gefällt. Du grübelst und grübelst und grübelst … Plötzlich fällt dir auf was dich stört und du posaunst es laut raus:

Aber so muss jede Ansicht die Informationen immer pollen. Je mehr Ansichten wir unterstützen müssen, desto häufiger wird die Datensenke abgefragt. Damit machen wir das Programm super langsam und unsere Geschäftsführer werden sich auch nicht gerade freuen.

Es muss doch eine Möglichkeit geben das die Klasse die die Daten sammelt die Ansichten über Neuerungen informiert?!

Observer Pattern oder Erkenntnis

Und diese gibt es auch. Sie nennt sich Observer Pattern. Sie wird in einigen Sprachen im großen Stile verwendet und mindestens eine Implementierung wird von der API angeboten zur eigenen Nutzung. Doch wie sieht sie aus?

Im Grunde sieht es so aus, das die Klasse die aktualisierte Daten zur Verfügung stellt eine Liste von zu Benachrichtigenden hat und bei Änderungen diese benachrichtigt.

Sequenzdiagramm Obserable Observer

Die Benachrichtigende Klasse nennt man Subject/Observable oder auf deutsch Subjekt. Die Klassen die benachrichtigt werden nennt man Observer oder auf deutsch Beobachter.

Dabei weiß das Observable nur das die Observer ein Interface Observer implementieren und wie es diesen den aktuellen Stand mitteilen kann.

Die Observer wissen über das Observable nur das es das Interface Observable implementiert und wie sie sich (de-) registrieren können.

Auch hier wird nur auf ein Interface programmiert und damit den Objektorientierten Prinzipien genüge getan.

Observer_Observable mit Implementierung Datensammler / Ansichten

Mit dem Entwurf gehst du zu deinen Kollegen und erntest Anerkennung. Was für ein toller Entwurf. Auf diese Weise werden die Ansichten über Veränderungen benachrichtigt wenn sie möchten oder sie können die Daten über die Getter-Methoden des Datensammlers abholen. Deine Kollegen beglückwünschen dich zu deinem ersten Entwurf mit dem Observer Pattern und ich tue es auch.

Hat dir mein Artikel gefallen? Dann teile ihn mit Freunden oder Kollegen! Hast du etwas nicht verstanden oder möchtest du etwas zur Verbesserung des Artikels beitragen? Dann schreib in die Kommentare! Du hast eine weitere Quelle die den Artikel verbessern könnte? Immer in die Kommentare damit.