11.15 Ein Design-Pattern durch Beobachten von Änderungen 

Aus dem objektorientierten Design haben wir gelernt, dass Klassen nicht fest miteinander verzahnt, sondern lose gekoppelt sein sollen. Das bedeutet, Klassen sollten nicht zu viel über andere Klassen wissen, und die Interaktion soll über wohldefinierte Schnittstellen erfolgen, sodass die Klassen später noch verändert werden können. Die lose Kopplung hat viele Vorteile, da so die Wiederverwendung erhöht und das Programm änderungsfreundlicher wird. Wir wollen dies an einem Beispiel prüfen.

In einer Datenstruktur sollen Kundendaten gespeichert werden. Zu dieser Datenquelle gibt es eine grafische Oberfläche, die diese Daten anzeigt und verwaltet, etwa eine Eingabemaske. Wenn Daten eingegeben, gelöscht und verändert werden, sollen sie in die Datenstruktur übernommen werden. Den anderen Weg von der Datenstruktur in die Visualisierung werden wir gleich erst beleuchten. Bereits jetzt haben wir eine Verbindung zwischen Eingabemaske und Datenstruktur und wir müssen aufpassen, dass wir uns im Design nicht verzetteln, denn vermutlich läuft die Programmierung darauf hinaus, dass beide fest miteinander verbunden sind. Wahrscheinlich wird die grafische Oberfläche irgendwie über die Datenstruktur Bescheid wissen, und bei jeder Änderung in der Eingabemaske werden direkt Methoden der konkreten Datenstruktur aufgerufen. Das wollen wir vermeiden. Genauso haben wir nicht bedacht, was passiert, wenn nun in Folge weiterer Programmversionen eine grafische Repräsentation der Daten etwa in Form eines Balkendiagramms gezeichnet wird. Und was geschieht, wenn der Inhalt der Datenstruktur über andere Programmfunktionen geändert wird und dann einen Neuaufbau der Bildschirmdarstellung erzwingt? Hier verfangen wir uns in einem Wollknäuel von Methodenaufrufen und änderungsfreundlich ist dies dann auch nicht mehr. Was ist, wenn wir nun unsere selbst gestrickte Datenstruktur durch eine SQL-Datenbank ersetzen wollen?

11.15.1 Design-Pattern 

Wir sind nicht die Ersten, die sich über grundlegende Design-Kriterien Gedanken machen. Vor dem objektorientierten Programmieren (OO) gab es das strukturierte und die Entwickler waren froh, mit Werkzeugen schneller und einfacher Software bauen zu können. Auch die Assembler-Programmierer waren erfreut, strukturiertes Programmieren zur Effizienzsteigerung einsetzen zu können – sie haben ja auch Unterprogramme nur deswegen eingesetzt, weil sich mit ihnen wieder ein paar Bytes sparen ließen. Doch nach Assembler und strukturiertem Programmieren sind wir nun bei der Objektorientierung angelangt, und dahinter zeichnet sich bisher kein revolutionäres Programmierparadigma ab. Die Softwarekrise hat zu neuen Konzepten geführt, jedoch merkt fast jedes Entwicklungsteam, dass OO nicht alles ist, sondern nur ein verwunderter Ausspruch nach drei Jahren Entwicklungsarbeit an einem schönen Finanzprogramm: »Oh Oh, alles Mist«. So schön OO auch ist; wenn sich 10.000 Klassen im Klassendiagramm tummeln, ist das genauso unübersichtlich wie ein FORTRAN-Programm mit 10.000 Zeilen. Es fehlt demnach eine Ebene über den einzelnen Klassen und Objekten, denn die Objekte selbst sind nicht das Problem, vielmehr ist es die Kopplung. Hier helfen nun Regeln weiter, die unter dem Stichwort Entwurfsmuster (engl. Design-Pattern) bekannt geworden sind. Dies sind Tipps von Softwaredesignern, denen aufgefallen ist, dass viele Probleme auf ähnliche Weise gelöst werden können. Sie stellten daher Regelwerke mit Lösungsmustern auf, die optimale Wiederverwendung von Bausteinen und Änderungsfreundlichkeit aufweisen. Design-Pattern ziehen sich durch die ganze Java-Klassenbibliothek und die bekanntesten sind Beobachter (Observer)-Pattern, Fabrik (Factory) und Composite.

11.15.2 Das Beobachter-Pattern (Observer/Observable) 

Wir wollen uns nun mit dem Observer-Pattern beschäftigen, welches seine Ursprünge in Smalltalk-80 hat. Dort ist es jedoch etwas erweitert unter dem Namen MVC (Model-View-Controller) bekannt, ein Kürzel, womit auch wir uns noch näher beschäftigen müssen, da dies ein ganz wesentliches Konzept bei der Programmierung grafischer Bedieneroberflächen mit Swing ist.

Stellen wir uns eine Party mit einer netten Gesellschaft vor. Hier finden sich zurückhaltende passive Gäste und aktive Erzähler. Die Zuhörer sind interessiert an den Gesprächen der Unterhalter. Da die Erzähler nun von den Zuhörern beobachtet werden, bekommen sie den Namen Beobachtete, auf Englisch auch Observable (von beobachtbar) genannt. Die Erzähler jedoch interessieren sich überhaupt nicht dafür, wer ihnen zuhört. Sie machen keine Unterscheidung zwischen ihren Zuhörern, sie halten allerdings den Mund, wenn ihnen überhaupt keiner zuhört. Die Zuhörer reagieren auf Witze der Unterhalter und werden dadurch zum Beobachter (engl. Observer).

Die Klasse Observable und die Schnittstelle Observer

Unser Beispiel mit den Erzählern und Zuhörern können wir auf Datenstrukturen übertragen. Die Datenstruktur lässt sich beobachten und wird zum Beobachteten. Sie wird in Java als Exemplar der Bibliotheksklasse Observable repräsentiert. Der Beobachter wird durch die Schnittstelle Observer abgedeckt und ist der, der informiert werden will, wenn sich die Datenstruktur ändert. Jedes Exemplar der Observable-Klasse informiert nun alle seine Horcher, wenn sich sein Zustand ändert. Denken wir wieder an unser ursprüngliches Beispiel mit der Visualisierung. Wenn wir nun zwei Sichten auf die Datenstruktur haben, etwa die Eingabemaske und ein Balkendiagramm, ist es der Datenstruktur egal, wer an den Änderungen interessiert ist. Ein anderes Beispiel: Die Datenstruktur enthält einen Wert, der durch einen Schieberegler und ein Textfeld angezeigt wird. Beide Bedienelemente wollen informiert werden, wenn sich dieser Wert ändert. Es gibt viele Beispiele für diese Konstellation, sodass die Java-Entwickler die Klasse Observable und die Schnittstelle Observer mit in die Standardbibliothek aufgenommen haben. Noch besser wäre die Entscheidung gewesen, die Funktionalität in die oberste Klasse Object aufzunehmen, so wie es Smalltalk macht.

Die Klasse Observable

Eine Klasse, deren Exemplare sich beobachten lassen, muss jede Änderung des Objektzustands nach außen hin mitteilen. Dazu bietet die Klasse Observable die Methoden setChanged() und notifyObservers() an.

Wir wollen nun das Party-Szenario in Java implementieren. Dazu schreiben wir eine Klasse Witzeerzaehler, deren Objekte einen Witz erzählen können, mit setChanged() auf eine Änderung ihres Zustands aufmerksam machen und dann mit notifyObservers() die Zuhörer mit dem Witz in Form einer Zeichenkette versorgen.

Listing 11.18   Witzeerzaehler.java

class Witzeerzaehler extends Observable

{
  public void erzähleWitz( String witz )
  {
    setChanged();

    notifyObservers( witz );
  }
}

setChanged() setzt intern ein Flag, das von notifyObservers() abgefragt wird. Nach dem Aufruf vom notifyObservers() wird dieses Flag wieder gelöscht. Dies kann auch manuell mit clearChanged() geschehen. notifyObservers() sendet nur dann eine Benachrichtigung an die Zuhörer, wenn auch das Flag gesetzt ist. So kommen folgende Programmzeilen häufig zusammen vor, da sie das Flag setzen und alle Zuhörer informieren.

setChanged();             // Eine Änderung ist aufgetreten
notifyObservers(Object);  // Informiere Observer über Änderung

Die notifyObservers()-Methode existiert auch ohne extra Parameter. Sie entspricht einem notifyObservers(null). Mit der Methode hasChanged() können wir herausfinden, ob das Flag der Änderung gesetzt ist.

Interessierte Beobachter müssen sich am Observerable-Objekt mit der Methode addObserver(Observer) anmelden. Dabei sind aber nicht beliebige Objekte als Beobachter erlaubt, sondern nur solche, die die Schnittstelle Observer implementieren. Sie können sich mit deleteObserver(Observer) wieder abmelden. Die Anzahl der angemeldeten Observer bekommen wir mit countObservers(). Leider ist die Namensgebung etwas unglücklich, da Klassen mit der Endung »able« eigentlich immer Schnittstellen sein sollen. Genau das ist hier aber nicht der Fall. Der Name Observer bezeichnet überraschenderweise eine Schnittstelle und hinter dem Namen Observable verbirgt sich eine echte Klasse.

Die Schnittstelle Observer

Das aktive Objekt, der Sender der Nachrichten, ist ein Exemplar der Klasse Observable, das Benachrichtigungen an angemeldete Objekte schickt. Das aktive Objekt informiert alle zuhörenden Objekte, die dazu die Schnittstelle Observer implementieren müssen. Damit versprechen sie, die Methode update(Observable, Object) zu implementieren, die bei Änderungen vom Observable-Objekt aufgerufen wird.

Die Schnittstelle Observer besteht im Übrigen nur aus dieser einen Methode. Der zweite Parameter ist genau die Nachricht, die mit notifyObservers() verschickt wurde. Bei der parameterlosen Variante notifyObservers() ist das Argument null. Somit können wir für die Party auch die Zuhörer implementieren.

Listing 11.19   Zuhoerer.java

class Zuhoerer implements Observer

{
  private String name;

  Zuhoerer( String name )
  {
    this.name = name;
  }

  public void update( Observable o, Object obj )

  {
    System.out.println( name + " lacht über \"" + obj + "\"" );
  }
}

Da auf einer echten Party die Zuhörer und Erzähler¹  nicht fehlen dürfen, baut die dritte Klasse Party nun echte Stimmung auf.

Listing 11.20   Party.java

import java.util.*;

public class Party
{
  public static void main( String args[] )
  {
    Zuhoerer achim = new Zuhoerer( "Achim" );
    Zuhoerer michael = new Zuhoerer( "Michael" );

    Witzeerzaehler ulli = new Witzeerzaehler();

    ulli.addObserver( achim );
    ulli.erzähleWitz( "Sorry, aber du siehst so aus, wie ich "+
                      "mich fühle." ); );
    ulli.erzähleWitz( "Eine Null kann ein bestehendes Problem " +
                      "verzehnfachen.");

    ulli.addObserver( michael );

    ulli.erzähleWitz( "Wer zuletzt lacht, hat es nicht eher " +
                      "begriffen." );
    ulli.erzähleWitz( "Wer zuletzt lacht, stirbt wenigstens " +
                      "fröhlich." );

    ulli.deleteObserver( achim );

    ulli.erzähleWitz( "Unsere Luft hat einen Vorteil: Man "+
                      "sieht, was man einatmet." );
  }
}

Wir melden zwei Zuhörer nacheinander an und einen wieder ab. Dann ist die Ausgabe:

Achim lacht über »Sorry, aber du siehst so aus, wie ich mich fühle.«

Achim lacht über »Eine Null kann ein bestehendes Problem verzehnfachen.«

Michael lacht über »Wer zuletzt lacht, hat es nicht eher begriffen.«

Achim lacht über »Wer zuletzt lacht, hat es nicht eher begriffen.«

Michael lacht über »Wer zuletzt lacht, stirbt wenigstens fröhlich.«

Achim lacht über »Wer zuletzt lacht, stirbt wenigstens fröhlich.«

Michael lacht über »Unsere Luft hat einen Vorteil: Man sieht, was man einatmet.«

¹   Eigentlich müsste ja Daniela die Witze erzählen ...