Klasse die zwei Aufgaben übernimmt?

[Samuel]

Ich weiß, ich nerve mal wieder mit änhlichen Fragen, aber auf die letzte gabs keine Antwort

Ich bin immernoch beim Risiko, kurzer Abriss nochmal, es gibt eine Klasse, die ein Teil des Modell ist, sie heißt SpielbrettWelt von mir aus und legt intern die Länder der Welt im System dar, Namen , Nachbarn usw, also rein Datenbezogen.
Nun muss man dies auch noch ausgeben, da die Klasse aber ein Teil des Modell ists, sollte sich doch nicht auch noch IO besitzen, oder? Sehe ich hoffentlich richtig.
Wie löst man sowas? Sollte ich mir noch eine Zusätzliche GUISPielbrettWelt anlegen, die nur das graphische anzeigen der Karte implementiert?
Diese GUISpielbrettWelt würde dann von der GUI allgemein genutzt um die Karte darzustellen.
Was mich interessiert, ist das eine logische Trennung? Ich könnte natürlich die Darstellung der Karte komplett in die GUI verlegen, worin ich aber einen Nachteil sehe, denn durch das System kann ich SpielBrettWelt leicht durch SpielBrettKaribik oder was auch immer austauschen und müsste dann nur noch eine GUISpielbrettKaribik haben, wäre GUI und GUISpielbrettKaribik aber eine Klasse, so müsste ich in der GUI rumwurschteln, obwohl es ja garnicht nötig ist, weil ja die GUI komplett unberührt bleibt, es ändert sich ja nur die Karte

 

[jank]

Generell ist es, meiner Meinung nach, eine sehr gute Idee, Spiellogik und grafische Ausgabe zu trennen. Das macht zum einen schon konzeptionell Sinn, denn das schreiben von Spielablauf/KI oder was auch immer ist ein ganz anderes paar Schuh als die grafische Ausgabe. Zum anderen kann dir das auch beim Entwickeln helfen, für die grafische Ausgabe schreibst du erstmal nur ein Skeleton, welches z.B. vorerst nur Text ausgibt. Dann kannst du dich mit dem Grafikkram (bin da nen gebranntes Kind :wink: ) später rumschlagen.

Grüsse,
Tin

 

[bygones]

es sollte eine abstrakte Klasse bzw ein interface existieren, dass das Gerüst von SpielbrettWelt definiert. Daneben gibt es Implementierungen des ganzen in der Modelebene und GUIs, die allein mit der abstr. Klasse oder mit dem Interface arbeiten und das ganze visualisieren, also zur View ebene gehören.

Eins sollte dir aber noch bewusst sein: Das MVC Prinzip ist eine optimale theorie, die es gilt zu verfolgen. Dennoch gibt es einige Sitautionen in der Wirklichkeit, in der das straffe folgen des Prinzips zu umständlich und zu komplex sind. D.h. man sollte stets die Vor und Nachteile des Ganzen abwägen und auch manchmal vielleicht das MVC Prinzip verletzen - ist ähnlich bei den Normalformen bei Datenbanken... beides genial in der Theorie, aber nicht immer umsetzbar in der Praxis

 

[Samuel]

Genauso hab ich es
Eine abstrakte Klasse für die die KArte der GUI Ebene und eine abstrakte Klasse für das Spielbrett der Modellebene.

Puuh

Danke