OOP mit Java: Modell View Controller Architekturmuster

MVC	Model View Controller Architekturmuster
	Ein Schema zur Trennung von Eingabe, Verarbeitung und Ausgabe in grafisch orientierter Software

Idee	übernommen aus dem alten EVA Ansatz:
	Eingabe -> Verarbeitung -> Ausgabe

Eingabe controller	read() scanf()

Ausgabe view	write() printf()

Verarbeitung model	keine Ein- und Ausgabe

Modularisierung	in Eingabe-, Verarbeitungs- und Ausgabemodul
	Änderung der Benutzungsschnittstelle ohne Änderung der Verarbeitung
	Wiederverwendung

	immer wieder schlechte Beispiele, auch in OO-Büchern:
	Klassisches Beispiel: Konversion einer Datenstruktur in einen Text und Ausgabe

grafische Benutzungsschnittstelle	in grafischen Umgebungen wird die Trennung in Eingabe, Verarbeitung und Ausgabe von den Werkzeugen häufig nicht unterstützt.
Beispiel	grafisches Objekt Auswahlliste
model	enthält eine Liste von Werten
view	eine Darstellung, Layout, Höhe, Breite, ...
controller	reagiert auf Eingaben, Ereignisse, markieren, klicken, ...

	keine Trennung von Eingabe, Verarbeitung und Ausgabe
	Wiederverwendung, Anpassbarkeit, Veränderbarkeit

MVC
model	enthält die internen Datenstrukturen und ihre Verarbeitungsroutinen
view	enthält die Darstellung der Daten, die Ausgabe
controller	enthält die grafischen Eingabeelemente

	lose Kopplung zwischen den drei Komponenten
	Kommunikation über Ereignisse

	bei Programminitialisierung wird festgelegt, welche Komponenten auf welche Ereignisse reagieren.
	Die Komponenten selbst wissen nichts über die Existenz anderer Komponenten

	Kontrollfluss nicht mehr explizit im Programm sichtbar.
	Festlegung über event handler

Beispiel

Ein Zähler, der inkrementiert und dekrementiert werden kann, und dessen Wert in einem grafischen Objekt angezeigt wird.

0. Versuch: schlecht

Die MVC Variablen

  Button control1, control2;
  int    model;
  Label  view;
  ...
 
  control1 = new Button("+1");
  control2 = new Button("-1");
  model    = 0;
  view     = new Label();

Die Ereignisbehandlung

    control1.addActionListener
      (new ActionListener()
       {
         public
         void actionPerformed(ActionEvent e) {
           ++model;
           view.setText(Integer.toString(model));
         }
       }
      );
 
    control2.addActionListener
      (new ActionListener()
       {
         public
         void actionPerformed(ActionEvent e) {
           --model;
           view.setText(Integer.toString(model));
         }
       }
      );

Noch schlechter

aber nicht praxisfern:
Das model wird im view versteckt.

Das gleiche Beispiel wie eben
-1. Versuch: noch schlechter

Die MVC Variablen

  Button control1, control2;
  Label  view;
  ...
 
  control1 = new Button("+1");
  control2 = new Button("-1");
  view     = new Label();

Die Ereignisbehandlung

    control1.addActionListener
      (new ActionListener()
       {
         public
         void actionPerformed(ActionEvent e) {
           int i = Integer.valueOf(view.getText()
                                   ).intValue();
           view.setText(Integer.toString(i+1));
 
           // oder view.setText("" + (i+1));
         }
       }
      );
 
    control2.addActionListener
      (new ActionListener()
       {
         public
         void actionPerformed(ActionEvent e) {
           int i = Integer.valueOf(view.getText()
                                   ).intValue();
           view.setText(Integer.toString(i-1));
         }
       }
      );

	Eingabe, Verarbeitung und Ausgabe beliebig gemischt
Beispiele	zur schrittweisen Entkopplung der Komponenten
0. Versuch	keine Entkopplung
1. Verbesserung	controller und model/view getrennt
2. Verbesserung	model und view getrennt

Benutzerdefinierte Events

`EventObject`	die Basisklasse für alle events.
	AWT events werden aus `AWTEvent` abgeleitet.
	Schema:
	import java.util.EventObject; public class MyOwnEvent extends EventObject { protected MyEventData d; public MyOwnEvent(Object source, MyEventData d) { super(source); this.d = d; } public int getD() { return d; } }

`EventListener`	alle Schnittstellen für neue events werden aus dieser Schnittstelle abgeleitet. Die Schnittstelle selbst ist leer und dient als Markierung.
	Eine eigene Schnittstelle legt die Aufrufkonvention für die auszulösenden Methoden fest, im einfachsten Fall reicht eine Methode.
	Schema:
	import java.util.EventListener; public interface MyOwnListener extends EventListener { public void myOwnMethod(MyOwnEvent e); }

	Diese Schnittstelle muss von Objekten implementiert werden, die auf die Ereignisse reagieren wollen.

auf Ereignisse reagieren	Das event listener interface muss implementiert werden.
	Schema:
	public class MyView extends ... implements MyOwnListener { ... public void myOwnMethod(MyOwnEvent e) { // Daten aus e anzeigen ... } }

Ereignisse auslösen	Objekte, die Ereignisse auslösen wollen, müssen eine Liste von event listener verwalten
	Schema
	import java.util.Vector; public class AClass { // state variables ... private Vector stateChangedListeners; //-------------------- public AClass() { // ... stateChangedListeners = new Vector(); } //-------------------- public void aMethod(...) { // change some state variables ... notifyStateChanged(); } //-------------------- protected void notifyStateChanged() { Vector l; MyOwnEvent e = new MyOwnEvent(this,...); synchronized (this) { l = (Vector)stateChangedListeners.clone(); } for ( int i = 0; i < l.size(); ++i ) { ((MyOwnListener)l.elementAt(i)) .myOwnMethod(e); } } //-------------------- public synchronized void addMyOwnListener(MyOwnListener l) { stateChangedListeners.addElement(l); } //-------------------- public synchronized void removeMyOwnListener(MyOwnListener l) { stateChangedListeners.removeElement(l); } }

Namenskonvention
xxxEvent	die Ereignisklasse
xxxListener	die Schnittstelle für die event Verteilung, Methodennamen beliebig
addXxxListener, removeXxxListener	die Verwaltung der event listener

Modell View Controller Architekturmuster

Model View Controller Architektur und Ereignisse

Beispiel

Noch schlechter

Benutzerdefinierte Events