Java-Pattern Tutorial

Kapitel
Grundlagen Beispielcode UML-Darstellung Übung
Home

Einführung

GUI programmieren

Patterns

   MVC

Verzeichnisse

Hinweis: Ab diesen Seiten beginnt die Vierteilung der Kapitel. Begonnen wird mit den Grundlagen. Der Beispielcode ist illustriert und bildet zusammen mit den UML-Diagrammen den praktischen Teil.

Die Übung soll auf Grundlage des vermittelten Stoffs bearbeitet werden. Je nach Aufgabentyp sollte der Lieblingseditor oder ein Blatt Papier zur Seite stehen.

MVC-Pattern

Das MVC-Pattern (Model-View-Controller) stammt noch von Smalltalk. Es entstand aus dem Bedürfnis nach einer Oberflächenprogrammierung, die leicht erweiterbar und anpassbar ist.

Bildhaft gesprochen ist es die Verwirklichung von verschiedenen Sichten auf ein und dasselbe Objekt. So ist eine Tabellenkalkulation mit seinen Zahlen und Diagrammen ein gutes Beispiel.

Wird an den Daten eine Änderung vorgenommen, so muss das damit verbundene Diagramm die Änderung sofort anzeigen.

Das MVC-Pattern ist durch andere Muster erweiterbar:

  • Observer
  • Singleton

Das Observer-Pattern sorgt für die konsistente Anzeige, also den oben beschriebenen Updatemechanismus. Ein Observer wird z.B. bei C++ benötigt, nicht aber bei Smalltalk.

Beschreibung

Die Beschreibung wird in diesem Beispiel anhand der Vorlage von [Buschmann et al., 1996, S. 126] vorgenommen:

Das Model-View-Controller Pattern teilt eine interaktive Anwendung in drei Bestandteile auf.

  • Das Model enthält die Kern-Funktionalität und Daten.
  • Die Views zeigen Informationen an.
  • Die Controller bearbeiten die Benutzereingaben.

Alle Views und Controller zusammen stellen das User Interface dar. Ein Änderungs-Meldungsmechanismus stellt die Konsistenz zwischen der Benutzerschnittstelle und dem Model sicher.

Name

Modell-View-Controller

Situation

Interaktive Anwendung mit einer flexiblen Mensch-Computer-Schnittstelle.

Problem

Benutzerschnittstellen sind besonders anfällig gegenüber sich ändernden Kundenwünschen. Ständig müssen neue Funktionen eingefügt oder neue Benutzerschnittstellen erstellt werden --> eine solche Änderung beeinflusst viele Module.

Einflüsse auf die Lösung:

  • Ein und die selbe Information wird unterschiedlich (als Balken- und Kuchendiagramm) in unterschiedlichen Fenstern angezeigt.
  • Sowohl Monitor als auch das Verhalten der Anwendung muss sofort auf Datenmanipulation reagieren.
  • Änderungen an der Benutzerschnittstelle (UI) sollen leicht und während der Laufzeit möglich sein.
  • Die Unterstützung verschiedener "Look-and-Feel"-Standards und die Umsetzung der Benutzerschnittstelle auf andere Plattformen sollten den Code der Hauptanwendung nicht beeinflussen.

Abb. 3.2: MVC-Pattern

Lösung

Das MVC-Pattern wurde zuerst in Smalltalk eingesetzt. Hier wurden eine interaktive Anwendung in drei Gebiete eingeteilt: processing (Verarbeitung), output (Ausgabe) und input (Eingabe).

Der Model-Bestandteil enthält die Hauptdaten und Hauptfunktionen und ist unabhängig von speziellen Ein- und Ausgabeaufgaben.

Der View-Bestandteil stellt dem Anwender Informationen dar.  Ein View erhält die Daten vom Model. Es kann viele Views eines Models geben.

Jeder View hat einen entsprechenden Controller. Controller erhalten Eingaben durch Ereignisse (events), die Mausklicks, Mausbewegungen oder Tastatureingaben in Code umsetzen.

Ereignisse werden übersetzt, um den Anfragen durch Model und View zur Verfügung zu stehen. Der Benutzer arbeitet und kommuniziert nur über den Controller mit dem System.

Die Unterscheidung des Models von View- und Controller-Bestandteilen erlaubt vielfältige Ansichten des Models. Wenn der Anwender das Model über den Controller eines bestimmten Views ändert, sollten alle anderen Views, die von diesen Daten abhängig sind , diese Änderungen zeigen. Deswegen teilt das Model allen Views jederzeit seine Änderungen mit. Die Views holen die neuen Daten vom Model ab und erneuern die angezeigten Informationen.

Struktur

Die Beschreibung der Struktur erfolgt über so genannte CRC-Diagramme (Class-Responsibilities-Collaborators = Klasse-Verantwortlichkeiten-Beteiligte). CRC-Diagramme enthalten die zu beschreibende Klasse. Die Verantwortlichkeiten enthalten die Attribute und Methoden, die zur Bewältigung der Aufgaben gehören. Die Beteiligten stellen andere Klassen dar, die im Zusammenhang mit dieser Klasse stehen.

Class Model

Responsibilities Collaborations
  • stellt funktionalen Kern der Anwendung zur Verfügung
  • registriert abhängige Views und Controller
  • teilt abhängigen Bestandteilen Datenänderungen mit
  • View
  • Controller

Class View

Responsibilities Collaborations
  • erstellt und initialisiert seine zugehörigen Controller
  • zeigt dem Anwender Informationen an
  • führt die Update-Prozedur aus
  • abholen der Daten vom Model
  • View
  • Controller

Class Controller

Responsibilities Collaborations
  • nimmt Benutzereingaben als Ereignis entgegen
  • übersetzt Ereignisse, um Anfragen des Models zu dienen oder um Anfragen des Views anzuzeigen
  • führt die Update-Prozedur aus, falls benötigt
  • View
  • Controller
Als nächstes folgt das MVC-Beispiel aus [Denzel, 2002] (Skript OOD) aus dem zweiten Semester.