HSG

Aktuelle Seite: HSG/Fächer/Informatik/Python/OOP

"M is for Model, V is for View, C is for Controller and together this framework works better for you."

MVC Film Video auf youtube www.railsenvy.com, mvc_song.mp3, mvc1.txt, mvc2.txt, mvc4.txt

MVC-Song

Das MVC-Muster sollte besser ein MVC-Muster heißen, da es verschiedene Interpretationen gibt. Eine Ausprägung beschreibt James Dempsey in seinem MVC-Song, der in youtube zu finden ist. Folgende Links sind eine Hilfe bei der Übersetzung.

Theodor Rau, MSS11, Abitur 2012 hat eine schöne Übersetzung erstellt.

Einführendes Beispiel

Es soll ein Programm geschrieben werden, das mit Hilfe einer grafischen Benutzungsoberfläche die mehrmalige Berechnung des ggTs ermöglicht. Die GUI könnte etwa folgendermaßen aussehen:

ggt-GUI

MVC-Schema

Ein Programm mit grafischer Oberfläche soll so konzipiert sein, dass es arbeitsteilig im Team entwickelt werden kann und ein hohes Maß an Wiederverwertbarkeit besitzt. Eine strikte Trennung des Fachkonzepts (Model) von der grafischen Präsentation (View) erfüllt diese Vorgaben. Im Idealfall wissen Model und View nichts voneinander. Die notwendigen Verbindungen werden nur von einem drittem Bestandteil, dem Controller, ausgeführt. Der Controller braucht dazu eine präzise Beschreibung der Schnittstellen von Model und View.

MVC-Schema

Definition

Die Menge aller öffentlichen Signaturen einer Klasse gehört zur Schnittstelle der Klasse. Zusätzlich enthält eine Schnittstelle semantische Festlegungen. Diese werden oft informell in Kommentaren oder durch selbsterklärende Methodennamen geliefert.

Grob gesagt: Eine Schnittstelle einer Klasse enthält alles, was ein Nutzer über die Klasse wissen muss.

Klassendiagramm

Im folgenden Diagramm werden zur Vereinfachung nur die Schnittstellen dargestellt.

Klassendiagramm ggt1.class.violet

Quelltext

einfache Realisierung ggt1.py, ggt2.py

Zweites Beispiel: Das Ziegenproblem

Problemstellung

Planung des Programms

View

Es muss eine Eingabemöglichkeit für die Türnummer (eTuer) geben und einen Button bWaehlen, der die Eingabe auslöst. Die Anzahl der Spiele und der gewonnenen Spiele und eventuell weitere Meldungen sollen angezeigt (lMeldung) werden.

Die View-Klasse kann weitgehend vom ggT-Beispiel übernommen werden (Copy&Paste-Warnung?).

Ziege 1 ziege1.py

Model

  • Attribute:
    • zustand wird anfänglich mit 1 belegt und gibt an, in welchem Teil des Spiels man sich befindet. Die Ereignisbehandlung von bWaehlen hängt von zustand ab.
    • autoplatz wird anfänglich zufällig mit 1,2 oder 3 belegt und gibt die Tür an, hinter der sich das Auto befindet
    • gewaehlt enthält die Nummer der gewählten Tür.
    • ziegentuer enthält die Nummer der Tür, die der Moderator öffnet.
    • spiele wird zu Beginn auf 0 gesetzt und gibt die Anzahl der Spiele an.
    • gewonnen wird zu Beginn auf 0 gesetzt und gibt die Anzahl der gewonnenen Spiele an.
  • Anwendungsfälle:
    • bWaehlen löst im zustand 1 Folgendes aus:
      • Die Nummer der gewählten Tür wird in der Variablen gewaehlt abgelegt.
      • Der Moderator öffnet zufällig eine ziegentuer, hinter der sicher eine Ziege steht (≠autoplatz) und die nicht gewählt (≠gewaehlt) ist.
        Verfeinerung zur Wahl der "Ziegen-Tür"
        Es gilt zwei Fälle zu unterscheiden: autoplatz ≠ gewaehlt und autoplatz = gewaehlt

        Im Fall "autoplatz &ne gewaehlt" gilt sicher autoplatz + gewaehlt + ziegentuer = 6. Daher lässt sich ziegentuer zu 6 - autoplatz - gewaehlt berechnen. Das ist ein bisschen trickreich, vermeidet aber viele Fallunterscheidungen.

        Der Fall "autoplatz = gewaehlt" macht mehr Probleme, da ziegentuer unter zwei Möglichkeiten zufällig gewählt werden muss.

        Lösungsmöglichkeit: Es werden drei Fälle für autoplatz unterschieden:
               from random import randint
               if autoplatz == 1:
                   ziegentuer = randint(2,3)
               elif autoplatz == 2:
                   if randint(1,2) == 1:
                       ziegentuer = 1
                   else
                       ziegentuer = 3
               elif autoplatz == 3:
                   ziegentuer = randint(1,2)
              
      • zustand wird auf 2 gesetzt, damit beim nächsten Drücken des Buttons bWaehlen eine andere Reaktion erfolgen kann.
    • bWaehlen löst im zustand 2 Folgendes aus:
      • Es wird eine Auswertung gemacht (autoplatz = gewaehlt?).
      • Es wird eine Meldung ausgegeben.
      • Die Statistik wird geführt und auf dem Bildschirm ausgegeben.
      • Ein neues Spiel wird vorbereitet (autoplatz zufällig belegen, zustand wieder auf 1 stellen).
  • Methoden:
    • ! ermittleZiegentuer()
    • ! ermittleAutoplatz()
    • ! werteaus() - Zähler erhöhen
    • ! reset() - Zähler zurücksetzen, Autoplatz zufällig wählen

Aufgaben

Ist in ziege2.py der Controller 'skinny' genug?

Teste Model aus ziege2.py, indem du auf der Shell 1000 Spiele mit der Wechseltaktik durchführst. Was ist zu erwarten?

Man kann ungestört mit den Klassen aus ziege2.py hantieren, wenn man die Erzeugung des Controllers auskommentiert.

Ziegentest

Man sieht, dass man mit Model ohne den 'Ballast' View viele Experimente in kurzer Zeit durchführen kann. Ein weiterer Vorteil der MVC-Architektur.

Aufgabe

Schreibe basierend auf das chuck-a-luck-model eine MVC-Realisierung des Spiels mit einer - einfachen - grafischen Oberfläche.

cal0.py, cal1.py

Aufgabe

'Spukschloss' - Dr. Bernd Kokavecz, museum0.py, museum1.py

Links

mvc1.txt, mvc4.txt