Mit dem Befehl jar xvf mvcbeispiel.jar wird das Archiv entpackt. Der Befehl java -jar mvcbeispiel.jar startet die Applikation.
Importieren Sie die Applikation auch in Ihr Eclipse-Arbeitsverzeichnis, so dass Sie den Quelltext dort bearbeiten und Ihrem Tutor im Testat vorführen können.
Erklären Sie Ihrem Tutor den Aufbau der Applikation und anhand dessen die allgemeine Idee hinter dem Model-View-Controller-Entwurfsmuster.
Die Applikation präsentiert beim Start lediglich eine funktionslose View. Implementieren Sie die beiden Varianten des Model-View-Controller-Entwurfsmuster mit Hilfe des Observer/Observable-Design-Patterns:
1. So wie in der Vorlesung vorgestellt, derart, dass die View das Model beobachtet und benachrichtigt wird, wenn sich dort etwas geändert hat.
2. So wie in der Übung vorgestellt, derart, dass der Controller das Model beobachtet und benachrichtigt wird, wenn sich dort etwas geändert hat.
Für diesen Aufgabenteil reicht es, wenn Sie die beiden Buttons mit Funktionalität versehen, so dass sich bei einem Klick auf den Erhöhe-Button der Wert im Model um 1 erhöht, beim Verringern um 1 erniedrigt. Im JLabel in der Mitte soll immer der aktuelle Wert angezeigt werden.
Ergänzen Sie außerdem eine geeignete (doppelte) Fehlerbehandlung, die dafür sorgt, dass sich der Zahlwert immer nur im Intervall von 0 bis 100 bewegen kann.
Musterlösung vom 16.04.2010:
Model View Controller
Das Model-View-Controller Pattern ist ein sehr weit verbreitetes Konzept zur Strukturierung von Softwareprogrammen. Die grundsätzliche Idee dabei besteht darin, den Aufbau eines Programms komponentenweise in drei Teile zu trennen: Eben Model, View und Controller. Ziel dabei ist es, einzelne Teile des Codes möglichst wiederverwertbar gestalten zu können. Dies soll dazu führen, dass man Programme einfacher erweitern oder ändern kann.
Model
Im Model werden alle Daten einer Applikation abgelegt und Teile der grundlegenden Manipulationslogik. Im vorgegebenen Beispiel wird dort die aktuell gewählte Zahl vorgehalten. Um das Model stets in einem sinnvollen Zustand zu halten, ist es sinnvoll Fehlerprüfung in den Manipulationsmethoden (hier beispielsweise setWert()) einzusetzen. Das Model enthält im allgemeinen keine reine Applikationslogik, es kann jedoch sinnvoll sein, dass beispielsweise grafische Objekte, wie eine Linie, neben ihrem Zustand (also beispielsweise den Eckpunkten und ihrer Farbe) auch weiß wie sie sich auf eine gegebene Oberfläche zeichnen kann. Dazu mehr auf dem nächsten Aufgabenblatt.
View
View-Objekte sind für die Darstellung von Daten verantwortlich und können Möglichkeit bieten, Daten durch den Benutzer zu ändern oder anzupassen. Die Daten selbst sind jedoch wie oben beschrieben im Model gespeichert. Um auch View-Objekte möglichst wiederverwertbar zu gestalten, ist es ratsam, diese in generischer Weise konfigurierbar zu machen. In der gegebenen Applikation ist in der Klasse ZaehlerView im Grunde ein Aussagen und Funktionsfreies JPanel konfiguriert, das grundsätzlich auch in jeder anderen Applikation mit anderm Zweck, als hier verwendet, zum Einsatz kommen könnte. Das gegebene Beispiel ist natürlich sehr akademisch, man kann sich vielleicht besser ein Fenster für eine Betriebssystem-Benachrichtigung vorstellen. Dieses zeigt immer einen Text und eine Menge von Buttons, welche Funktion das Fenster aber genau hat, muss in der View gar nicht definiert sein. Dies erledigt der Controller.
Controller
Für die Verbindung zwischen den möglichst generischen Views und den spezialisierten Model-Klassen sind die Controller verantwortlich. Im Allgemeinen kann man sagen, dass sie dafür sorgen, dass die Operationen, die ein User in einer View auslöst, an das entsprechende Model propagiert werden. Außerdem kann der Controller genutzt werden, um die View und das Model initial aufzubauen und miteinander bekannt zu machen. Im gegebenen Beispiel legt der Controller die für seinen Zweck nötige View an und konfiguriert diese - genau wie das entsprechende Model. Schließlich enthält der Controller den größten Teil der eigentlichen Applikationslogik, also den Teil der des Programmcodes, der die eigentlich geforderten Dinge tut. In der Beispielsapplikation legt er also alle nötigen Listener an und implementiert deren Logik: Was soll passieren, wenn ein Nutzer auf einen Button klickt? Was soll passieren, wenn ein Nutzer am Slider zieht?
Zusammenspiel
Während die Grenzen für die Zuständigkeit der einzelnen Teile des MVC-Patterns relativ deutlich abgegrenzt sind, gibt es für das Zusammenspiel im Wesentlichen zwei häufig eingesetzte Varianten.
|
|
In der linken Variante der oberen Abbildung, kommuniziert die View direkt mit dem Model. In der Aufgabe sollte hierzu das Observer/Observable-Pattern eingesetzt werden. Dabei erweitert eine Klasse die Systemklasse Observable und weitere Klassen, die das Interface Observer implementieren, können das Observable nun beobachten. Das Observable, hier das Model, wird im ersten Fall also von der View beobachtet und benachrichtigt diese per stateChanged und notfiyObservers über entsprechende Änderungen. Die View implementiert nun die Methode update, um sich entsprechend selbst zu ändern, wenn das Model seinen Zustand geändert hat.
In der zweiten (rechten) Variante kommuniziert die View überhaupt nicht direkt mit dem Model. Das Anpassen der View an den neuen Zustand erfolgt über den Controller, der diesmal der Observer ist und die View entsprechend anpasst.
Während beide Vorgehen zu einer sinnvollen Code-Strukturierung beitragen, hat letztere Methode den weiteren großen Vorteil, dass Model und View sich niemals direkt kennen müssen, so dass die View noch generischer gehalten werden kann. Sie muss also nicht wissen, welche Werte aus dem Model abgeholt werden müssen, um sich selbst anzupassen.
Lösung der Aufgabe
Die Quellen der Aufgaben können unter /home/cg/Uebung/Blatt1/Lsg/blatt01-aufg1-2.jar und /home/cg/Uebung/Blatt1/Lsg/blatt01-aufg1-1.jar heruntergeladen werden.