{"id":3326,"date":"2011-08-03T15:48:16","date_gmt":"2011-08-03T13:48:16","guid":{"rendered":"https:\/\/www.herr-rau.de\/wordpress\/?p=3326"},"modified":"2011-08-25T10:21:59","modified_gmt":"2011-08-25T08:21:59","slug":"wie-ich-auszog-ein-spiel-zu-programmieren-2-das-mvc-entwurfsmuster","status":"publish","type":"post","link":"https:\/\/www.herr-rau.de\/wordpress\/2011\/08\/wie-ich-auszog-ein-spiel-zu-programmieren-2-das-mvc-entwurfsmuster.htm","title":{"rendered":"Wie ich auszog, ein Spiel zu programmieren (2): Das MVC-Entwurfsmuster"},"content":{"rendered":"
(6 Kommentare.<\/a>)<\/small> <\/div>

(Fortsetzung hiervon.<\/a> Ich f\u00fcrchte, diesmal noch technischer.) Wir haben: Ein halbwegs fertiges Modell f\u00fcr ein generisches Brettspiel, mit einem Spielbrett beliebiger Gr\u00f6\u00dfe, bestehend aus rechtwinklig angeordneten Feldern (die, falls man das mal braucht, verschiedene Zust\u00e4nde annehmen k\u00f6nnen). Und wir haben Spielfiguren, die auf diesen Feldern stehen<\/p>\n

\"\" <\/p>\n

Was noch fehlt, sind Spielregeln und irgendetwas Sichtbares. Und das habe ich nach dem Bauprinzip Model-View-Controller<\/strong> gel\u00f6st, das explizit im Lehrplan f\u00fcr die 11. Klasse steht. Da ich in meinem zweij\u00e4hrigen Notstudium nichts von Entwurfsmustern geh\u00f6rt hatte, musste ich mich erst mal schlau machen. In den beiden Schulb\u00fcchern, die ich heranzog, stand das jeweils sehr \u00e4hnlich, aber nicht ganz gleich, und nur m\u00e4\u00dfig verst\u00e4ndlich. Die ISB-Handreichungen zu Informatik<\/a> stellten wieder andere Aspekte in den Vordergrund, Wikipedia auch, und \u00fcberhaupt gibt es MVC in verschiedenen Abwandlungen, die f\u00fcr Programmierer eine gr\u00f6\u00dfere Rolle spielen als f\u00fcr Informatiklehrer und -sch\u00fcler.<\/p>\n

(Sehr anschaulich dargestellt ist MVC in den Programmierbeispielen dieses Threads eines Java-Forums<\/a>. Wenn man die Beispiele kopiert und in einem eigenen Projekt ausprobiert, kapiert man schnell, worum es geht.)<\/p>\n

Jedenfalls erkl\u00e4re ich jetzt mein<\/em> MVC.<\/p>\n

Erstens: Das Model.<\/h4>\n

\"\"<\/p>\n

Das Model stellt quasi das Spielmaterial dar. Es besteht aus Objekten (Spielfiguren) mit bestimmten Zust\u00e4nden (Position, Gesundheitszustand). Das Model stellt Methoden zur Verf\u00fcgung, mit denen man diese Zust\u00e4nde ver\u00e4ndern kann. Detaillierter ist das im letzten Beitrag<\/a> beschrieben.<\/p>\n

Zweitens: Model – und View als Darstellung.<\/h4>\n

\"\"<\/p>\n

Damit man das Modell auch anschauen kann und nicht blind Schach spielen muss, gibt es mindestens einen View (eine Ansicht). Der View stellt die Inhalte des Modells f\u00fcr den Benutzer grafisch dar. Er ist quasi die Ausgabeeinheit unseres Projekts. Immer, wenn sich am Modell etwas Nennenswertes \u00e4ndert, schickt es Informationen an den View, der diese Informationen dann (sofern n\u00f6tig) grafisch umsetzt.<\/p>\n

Bei mir sieht das dann in der Rohform so aus:<\/p>\n

\"\"<\/p>\n

Das ist ein 5×5-Spielfeld mit drei Figuren verschiedener Art darauf. Die einzelnen Felder sind von zweierlei Typen. Rechts sind Kn\u00f6pfe und Informationen, die interessieren uns jetzt noch gar nicht. <\/p>\n

Ich habe oben gesagt, dass es mindestens einen View gibt. Tats\u00e4chlich gibt es oft mehrere Ansichten, bei mir bisher zwei: die grafische Darstellung und eine Art schriftliche Mitprotokollierung. Das kennt man ja auch vom Schach, dass da die Z\u00fcge aufgeschrieben werden.<\/p>\n

\"\"<\/p>\n

Sp\u00e4ter m\u00f6chte ich den Text nat\u00fcrlich noch etwas epischer verfassen. — Aber auch mehrere gleichzeitige grafische Views sind bei einem Spiel denkbar: eine Ansicht von oben und eine von der Seite, der \u00dcbersichtlichkeit halber. Oder ein View f\u00fcr Spieler 1 und ein zweiter f\u00fcr Spieler 2, bei dem jeweils die Typen der gegnerischen Spielfiguren ausgeblendet sind, wie man das f\u00fcr Stratego<\/a> br\u00e4uchte. Deshalb ist MVC \u00fcblicherweise so angelegt, dass man leicht neue Views hinzuf\u00fcgen kann, ohne am Model auch nur das Geringste \u00e4ndern zu m\u00fcssen (=> Beobachter-Entwurfsmuster).<\/p>\n

Knackpunkt bei dem Verh\u00e4ltnis zwischen Model und View(s) ist der, dass man vorher klarmachen und festhalten muss, welche Botschaften das Model an den View schicken kann. In meinem Fall sind das bisher:<\/p>\n