Design Patterns 2. Model-View-Controller in der Praxis

Design Patterns 2 Model-View-Controller in der Praxis

Design Patterns Oft Schablonen für eine Klassenstruktur... aber nicht immer! Dahinterliegende Konzepte wichtiger als wörtliche Umsetzung Pattern werden oft kombiniert ggf. sogar mit sich selbst

Separation of Concerns (Trennung der Zuständigkeiten) Eines der wichtigsten Prinzipien: Verbessert die Modularität, und macht damit den Code erweiterbarer, erlaubt mehr unabhängige Änderungen (Teamarbeit) und oft den Code sogar einfacher Viele Design Patterns helfen dabei: Iterator, Collection, Factory, MVC

MVC als Separation of Concerns MVC vereinfacht: View Controller Model Trennung der Zuständigkeiten! Model: Daten (und Datenlogik) View: Präsentation Controller: Kommunikation (= mediating-controller MVC, Model View Adapter MVA)

MVC MVC!= 3 Klassen: Model, View, Controller Eher: getrennte Packages! Dann wirklich umgesetzt, wenn man unterschiedliche Models/Views ermöglicht! MVC ist ein Pattern dass oft mehrfach in der gleichen Anwendung verwendet wird!

Hierarchisches MVC Beispiel JTextField View ActionListener Controller DataObject Model Aber was passiert im JTextField?

Hierarchisches MVC Beispiel TextUI View JTextField Controller Document Model Swing-Komponenten implementieren selbst eine Variante des MVC Patterns! Also: MVC in der View. auch im Model?

Logik im Controller oder Modell? Traditionell: dumme Datenobjekte, alle Logik ist im Controller ( setkontostand ) Zunehmend populär: Logik in intelligenten Datenobjekten Oft hybride Lösungen: UI Controller übersetzt UI-Events (Klicks etc.) in logische Operationen (Kommandos) Data Controller übersetzt Kommandos in Änderungen am Datenmodell

MVC komplexer UI Controller Spielzug Spielregeln Controller Ergebnis Daten Controller Klick Änderung UI Zustand Direkte Kommunikation sinnvoll? Spielfeld Zustand viele Instanzen des MVC Patterns!

MVC noch komplexer... Swing UI oder JavaFX UI Lokale Daten Sound- Effekte Kommunikation Controller Gamepad- Steuerung Netzwerk Daten

MVC auf Mikro-Ebene passiv? GameEngine Controller testcollission() hit() StoneRenderer View StoneChangedEvent StoneObject Model Im Kleinen oft leichter realisierbar Aufgabentrennung: Renderer vs. Model Manchmal eine passive view Manchmal Direktzugriff auf Modell sinnvoll

Vorteile Getrennte Entwicklung möglich Bspw. Soundeffekte eigene View Bspw. Steuerung eigene View Getrenntes Testen möglich: Statt Maus -Spieler: Computerspieler Statt graphischer Darstellung: Unittests Bei großen Projekten: einfacherer Code (weniger Abhängigkeiten) verschiedene Versionen möglich viel schnellere Entwicklung

Aggregate zur Verwaltung Game Object Renderer Model gehört zur View gehört zum Controller gehört zum Modell Hier: intern MVC Aggregation zur Verwaltung bspw. auf Ebene des Controllers Aber möglichst mehrere Views erlauben! (Bspw. Audio, Swing, Maus)

MVC als Kombination von Patterns View als Observer, Model als Observable View beobachtet das Modell Controller: als Strategy pattern View delegiert User-Eingaben an Controller View als Composite Besteht i.d.r. aus vielen Komponenten MVC daher für manche kein echtes Pattern sondern einfach nur eine mögliche Instanzierung von diesen bestehenden Pattern.

Strategy Pattern interface Formel { } double berechnen(double x, double y); public class Addition implements Formel { public double berechnen(double x, double y){ return x + y; } }

Strategy Pattern public class Rechner { Formel formel = new Addition();...... double ergebnis=formel.berechnen(x,y); } void setformel(formel formel) { } this.formel = formel;

Strategy Pattern Austauschbar und Modular Ideal für Zustände (state = new Ausverkauft()) Spielregeln Zugriffskontrolle Logging Konfiguration

State Pattern Eng verwandt mit dem Strategy Pattern Oft so verwendet: zustand = zustand.macheetwas(); neuer Zustand alter Zustand Ähnelt Automaten (vgl. Automatentheorie)