Das Entwurfsmuster Model-View-Controller

Die Geschichte hinter MVC Bereits sehr früh in der Geschichte der Softwareentwicklung machten Programmierer die Erfahrung, dass Programme mit wachsender Größe die Tendenz haben, so unübersichtlich zu werden, dass niemand mehr den Code verstehen kann. Um dem entgegenzuwirken, erfand man in den 1970er Jahren Model-View-Controller (MVC), das eine systematische Ordnung in den Code zu bringen versuchte. Dies geschah also lange vor der Erfindung von Java in einer heute kaum noch bekannten objektorientierten Sprache namens Smalltalk. MVC hat sich über die Jahre so sehr bewährt, dass es zum ältesten und bis heute noch einem der komplexesten Entwurfsmuster wurde.

MVC unterteilt den Code in drei Komponenten: Aufbau von MVC MVC unterteilt den Code in drei Komponenten: Das Modell (engl. Model) enthält die eigentlichen Funktionalitäten des Programms. Die Sicht (oder Präsentation, engl. View) übernimmt den Dialog mit dem Benutzer. Einerseits stellt sie alle relevanten Informationen des Models übersichtlich dar. Andererseits nimmt sie Eingaben des Benutzers entgegen. Die Steuerung (engl. Controller) überwacht die Tätigkeit von Model und View und gibt beiden die notwendigen Befehle. Der Controller enthält also nur die Programmlogik und wird damit meistens schlank im Vergleich zu Model und View. Das ist ein großer Vorteil gegenüber Nicht-MVC-Projekten, bei denen die Logik oft über viele Klassen verstreut ist.

„Klassendiagramm“ von MVC Das Zusammenwirken der drei Komponenten lässt sich wie folgt veranschaulichen: Controller View Model beobachtet > informiert > < steuert steuert > Das Zusammenspiel zwischen View und Model wird dabei mit dem Entwurfsmuster Beobachter realisiert. Dadurch hat der Controller zunächst nichts mit der Kommunikation zwischen View und Model zu tun, sondern die View reagiert selbstständig auf jede relevante Veränderung im Model. Auch dieser Ansatz hält den Controller schlank.

Verwendung von Schnittstellen Sinnvollerweise programmiert man zunächst Schnittstellen für Model, View und Controller und schreibt erst dann konkrete Klassen für jeden der drei Teile. Das hat den Vorteil, dass alle drei Teile unabhängig voneinander austauschbar sind. In unserem Labyrinthspiel wären zum Beispiel folgende Ersetzungen denkbar: Model: Statt dicken Wänden könnte man dünne Wände benutzen. Man könnte mehrere Stockwerke bauen. View: Statt in 3D könnte man das Labyrinth in 2D darstellen (oder einfach nur als beschreibenden Text). Controller: Man könnte unter bestimmten Umständen erlauben, durch Wände zu gehen (z. B. bei Geheimtüren).

Schritte der MVC-Programmierung Wir haben in unser Labyrinthspiel zusätzlich zum Ladenknopf auch noch einen Speichernknopf eingebaut. Dazu waren folgende Schritte nötig: In der View: Wir haben den Knopf erzeugt und ins Layout eingefügt. speichernknopf = new JButton ("Labyrinth speichern"); dialograum.add (speichernknopf); Wir haben dafür gesorgt, dass der Speichernknopf von der View beobachtet wurde. speichernknopf.addActionListener (this); Wenn der Speichernknopf gedrückt wurde, haben wir die Benutzerin gefragt, in welche Datei sie das Labyrinth speichern will, und dann dem Controller mitgeteilt, dass er dafür sorgen soll, dass das Labyrinth gespeichert wird. controller.speichereLabyrinth (...);

Schritte der MVC-Programmierung (2) Im Controller: Wir haben die Methode speichereLabyrinth () geschrieben, die den Auftrag, das Labyrinth zu speichern, an das Model weitergibt. model.speichereLabyrinth (labyrinthDatei); Nach dem Speichern haben wir nochmaliges Speichern verboten. view.erlaubeSpeichern (false); Wenn das Spiel sich durch Bewegen oder Marken setzen verändert hat, haben wir Speichern wieder erlaubt. view.erlaubeSpeichern (true);

Schritte der MVC-Programmierung (3) Im Model: Wir haben die Methode speichereLabyrinth () geschrieben. In der View: Wir haben die Methode erlaubeSpeichern () geschrieben, die den Speichernknopf ein- und ausschaltet. public void erlaubeSpeichern (boolean erlaubt) { speichernknopf.setEnabled (erlaubt); } Wir haben insgesamt also in allen drei Bestandteilen Model, View und Controller programmieren müssen, um die neue Funktionalität einzubauen. In jedem Bestandteil mussten wir die Schnittstelle und die implementierende Klasse ändern. Das war viel Arbeit, hielt aber den Code übersichtlich.