proggen.org

Hallo Programmierer,

ich möchte mithilfe des QT Designers ein vier-gewinnt spiel schreiben, tue mich aber etwas schwer mit dem aufbau und kapselung des quellcodes.
Könnte mir jemand dabei weiterhelfen, was die beste lösung ist softwarearchitekturmäßig? (sollte nicht zu kompliziert sein, bin noch ein anfänger) habe mir dazu mehrere tutorials angeschaut und jeder hat es anders gemacht, was mich eher verwirrt hat und ich jetzt nicht weiß, auf welche weise ich es umsetzen soll.es sollte objekotientiert sein. ich weiß, dass model-view ja an sich schon objektorientiertes programmieren ist, aber Ich überlege, ob ich

1.) einfach eine model klasse mache, wo alle daten, die ganzen methoden, spielbretterzeugung, etc. einfach reingehauen werden und eine
delegate-klasse, wo die logik reinkommt, quasi die schnittstelle zwischen model und view und den spielablauf steuert, also 2 klassen und fertig, oder

2.) eigene datentypen verwenden und eine extra klasse für spielfeld, spieler, spielchips, etc..
und wenn ich es so mache, hätte ich die frage, ob diese klassen alle dann zum model gehören, und wenn das so wäre, wie kann man diese klassen dann zu einem model zusammenfassen? erben dann die klassen spieler, feld, spielchip,etc von QAbstractItemModel und schon hätte man das model oder ist es komplizierter?

Ich wäre sehr dankbar für Tipps.

El Ávila hat geschrieben:Könnte mir jemand dabei weiterhelfen, was die beste lösung ist softwarearchitekturmäßig? (sollte nicht zu kompliziert sein, bin noch ein anfänger) habe mir dazu mehrere tutorials angeschaut und jeder hat es anders gemacht, was mich eher verwirrt hat und ich jetzt nicht weiß, auf welche weise ich es umsetzen soll.es sollte objekotientiert sein. ich weiß, dass model-view ja an sich schon objektorientiertes programmieren ist,

Uffz... fangen wir damit an, dass erstmal den Begriff "objektorientiert" vergisst.

Dann überlegen wir uns kurz, was Du brauchst. Du willst vier Gewinnt spielen. Du brauchst also erstmal eine Vorstellung, wie Du Deinen Spielzustand repräsentierst. Wie groß ist Dein Spielfeld, was ist ein Chip - die gibt es ja in verschiedenen Farben - wieviele Chips können pro Position (1) liegen... Das sind jetzt schon mehrere Datenstrukturen: Spielfeld, Chip, Spieler, welcher Spieler ist dran... Die Repräsentation Deines Spielstandes ist Dein Model.
Deine Datenstrukturen kannst Du mit Klassen darstellen. Musst Du aber nicht, solltest Du aber. Die Benutzung des Wortes "class" macht aus Deinem Programm aber kein OOP.

Dann musst Du den Spielstand irgendwie auf den Bildschirm bringen. Dein View fragt also dein Model, was es denn überhaupt darstellen soll. Dein View kann also Deinen Spielstand darstellen. Du kannst aber auch mal eben spontan einen anderen Spielstand darstellen. Wichtig ist: Dein View hat keine Daten über Deinen Spielstand, wenn Du also den Spielstand mal eben auswechseln möchtest, hängt nicht die Hälfte im View. Du musst nur ein anderes Model übergeben.
Mit wievielen Datenstrukturen Du Dein View umsetzt... Qt wird vermutlich reichlich Klassen dafür nutzen.

Bleibt das Control. Control weiß welches Model zu welcher Eingabe gehört und mit welchem/welchen View/s dargestellt wird. Und wenn eine Eingabe sagt "roter Chip in Säule 3", dann ändert Control das dazugehörige Model entsprechend ab. Es fragt auch vorher ab, ob der Spieler mit den roten Chips überhaupt dran ist.

El Ávila hat geschrieben:2.) eigene datentypen verwenden und eine extra klasse für spielfeld, spieler, spielchips, etc..
und wenn ich es so mache, hätte ich die frage, ob diese klassen alle dann zum model gehören, und wenn das so wäre, wie kann man diese klassen dann zu einem model zusammenfassen? erben dann die klassen spieler, feld, spielchip,etc von QAbstractItemModel und schon hätte man das model oder ist es komplizierter?

MVC ist ein Design Pattern und hat erstmal nichts mit Ableiten, OOP oder sonstwas zu tun. Es ist nicht komplizierter, es ist einfacher: Was zum Model gehört, definierst Du allein.
Der Hintergedanke ist - wie gesagt - dass es abschlossene Bereiche in der Software gibt, die gewisse Dinge nicht tun. View ändert nicht das Model. Model pfuscht nicht in der Darstellung herum. Die Spielregeln werden nicht in Model und auch nicht im View implementiert.
Sinn der Sache ist: Man kann große Bereiche einer Software ausschließen, wenn ein Fehler auftritt. Hat noch keiner einen Zug gemacht, aber ein Spieler bereits gewonnen, dann kannst Du alle Klassen ausschließen, die zum View gehören. Der Fehler kann entweder nur in der Spielstand-Repräsentation liegen (das Spielfeld ist beim Start bereits mit Chips gefüllt) oder im Control (ein Spieler wird zum Sieger erklärt, obwohl das Spielfeld leer ist). Im View wird der Fehler aber nicht zu finden sein.

Und wie gesagt, man kann den View-Bereich für verschiedene gleichzeitig laufende Spiele verwenden. Die können ja nix, die wissen nix, die stellen nur irgendwas da. Ob das jetzt ein anderes 4-Gewinnt-Spiel ist oder ein Spiel, was mit dem gleichen Spielfeld läuft.