Inhaltsverzeichnis
Weitere Design Patterns ("Entwurfsmuster", "Architekturmuster")
Wir haben bereits das Kompositum als Design Pattern kennengelernt.
Observer-Pattern
Das Observer-Muster dient der Benachrichtigung anderer (von einem Objekt abhängiger) Objekte über Änderungen. Die zu beobachtende Klasse (Subject) verfügt hierzu über die Möglichkeit, Beobachter an- und abzumelden sowie zum Benachrichtigen der angemeldeten Beobachter. Die Beobachterklasse (Observer) benötigt lediglich eine Methode, die bei Aktualisierung der beobachteten Klasse aufgerufen wird. Damit es zu einem Subject mehrere Observer geben kann, definiert man ein Interface, das alle Observer-Klassen implementieren.
Ein ausführlicheres Klassendiagramm finden Sie auf Wikipedia.
Ein Beispiel für das Observer-Pattern folgt gleich unten zusammen mit dem Model-View-Controller-Pattern.
Model-View-Controller Pattern
Die Model-Komponente enthält die zu verwaltenden Daten und besitzt Methoden zum Ändern der Daten. Die View-Komponente (Präsentationsschicht) dient zur Darstellung der Daten aus dem Modell (z.B. am Bildschirm oder auf einer Webseite) und zur Entgegennahme von Steuerbefehlen vom Benutzer (z.B. Eingaben über Tastatur und Maus). Der Controller ist die Steuerungseinheit, verwaltet die View-Komponente(n) und das Model und verarbeitet Befehle des Benutzers. Das Muster funktioniert nach dem Schema rechts (nicht als Klassendiagramm zu verstehen!).
Im Diagramm bezeichnen durchgezogene Pfeile direkte Assoziationen (die View "kennt" das Model, der Controller "kennt" Model und View), gestrichelte Pfeile bezeichnen indirekte Assoziationen, z.B. über das Observer-Pattern. So ist der Controller ein Observer der View, die den Controller bei Benutzereingaben verständigt. Die View ist ein Observer des Models, das die View verständigt, wenn sich die Daten geändert haben, damit die View die Darstellung entsprechend erneuert.
Das Observer-Muster ermöglicht es hier, eine Komponente über Änderungen (z.B. im Model) zu informieren, ohne dass diese beim Erstellen der Subject-Klasse direkt bekannt sein muss (im Sinne der oben eingezeichneten, durchgezogenen Pfeile). Ein Observer wird beim beobachteten Objekt (Subject) registriert (und kann auch wieder entfernt werden). Ferner besitzt jedes Subject eine Methode zur Aktualisierung (notify), die bei jedem registrierten Observer die Methode update aufruft.
Beispiel: Button, der Klicks zählt
Hier eine beispielhafte MVC-Implementierung eines Buttons, der zählt, wie oft auf ihn geklickt wurde und dies als Button-Beschriftung anzeigt.
In der Praxis wird man das MVC-Pattern nicht für so kleine Komponenten wie diesen Button verwenden. Eine Button-Klasse wäre vielmehr ein Bestandteil der View-Komponente. Bei großen Projekten ist das MVC-Pattern aber ungemein nützlich: Zum einen ermöglicht es, das Programm so zu gestalten, dass später die View-Komponente mit wenig Aufwand ausgetauscht werden kann (sie veraltet am schnellsten…) oder eine weitere View-Komponente hinzugefügt werden kann. Zum anderen hilft die Trennung zwischen Model, View und Controller, Ordnung zu halten und den Überblick zu bewahren.
Aufgabe 1
Im Programmierkasten unten findest Du den Beginn einer View-Klasse und einer Controller-Klasse für ein Schalterelement (siehe Bild rechts). Per Mausklick soll zwischen den Zuständen "aus" (grau) und "an" (grün) umgeschaltet werden können. Ergänze die beiden Klassen und schreibe eine geeignete Model-Klasse, so dass insgesamt das MVC-Pattern verwirklicht wird!