Programmlogik, wo ist die Main?

[Samuel]

Sagen wir ich möchte ein Spiel bauen (wurscht welches), so habe ich neben ner Menge anderer
Klassen zwei wichtige Klassen: Spiel und UIF.
Spiel enthält die ganze Programmlogik, kennt also die Regeln und alle relevanten Klassen.
Und ich habe das User Interface, welches später auch ein GUI implementiert, aber das ist ja latte.

Nun ist mir noch nicht ganz das logische Zwischenspiel der beiden im Bezug GUI/UIF klar, gehen wir erstmal von UIF aus:
Main ist in Klasse "Spiel".
Spiel legt sich Instanzen an, z.B. Spieler, für deren Namen benutzt es die Instanz oder static Methode der UIF.
Erste Frage, sagen wir, die UIF benutzt Konsole, wer von den beiden, Spiel oder UIF haben den String "Bitte Namen eingeben" ?
Das UIF, oder?
Ok, gehe ich mal davon aus, nun bekommt UIF eine gültige Eingabe in der Konsole und gibt den Wert an Spiel weiter, usw.

Nun das selbe bei einer GUI.
Wie kann man hier elegant arbeiten? Nehen wir als Beispiel mal Schiffe versenken.
Das UIF wurde erst dann aktiv, als der Name eigegeben werden musste.
Aber das GUI muss doch eigentlich viel früher aktiv werden, um Fenster zu erzeugen usw. Heißt dass, das wenn eine GUI da ist, die Main auf einmal in der GUI sein muss?
Es muss ja zuerst die Canvas da sein, wo man neues Spiel oder beendet usw wählt.
Bedeutet dass, das man bereits bei einer UIF schon so denken muss, dass die Main in der UIF drin ist? Und dass diese halt nur sowas wie Stubs der "zeichneFenster" Methoden hat?

Gehe ich davon aus, dass die Main in Spiel liegt, so kann ich zwar, wenn ich am Punkt der Namenseingabe bin, ebenso bequem anstatt der UIF die GUI nehmen, aber wo bleibt dann der Rest, der bei ner UIF nicht da war und bei der GUI da sein muss?

 

[Samuel]

Hui, ich hoffe, ich habe mich halbwegs verständlich ausgedrückt

 

[Roar]

ist doch schnurzegal wo die main liegt. bei mir liegt sie meistens eh immer in ner eignen klasse. war dasjetz deine frage? ???:L

 

[Samuel]

Ehm nein, ich habe mir eine fundiertere Erörterung des Themas aus der Sicht der OOA gewünscht.

Weil die Überlegung maßgeblich für die Entwicklung ist, denn main in Spiel würde bei einem wechseln von UIF zu GUI das Umschreiben des Spiels benötigen

 

[Roar]

wo ist bei dir der unterschied zwischen "UIF" (= User Interface?) und "GUI" (= Graphical User Interface) ? wenn du in deinem programm model, controller und uif anständig getrennt hat ist das egal ob das interface über die konsole geht oder über bunte bildchen.

wo ist die Main?

Heißt dass, das wenn eine GUI da ist, die Main auf einmal in der GUI sein muss?

hab ich so aufgefasst ???:L

wo die main liegt ist egal, am besten in keiner von den beiden teilen.

 

[Samuel]

Ja ok, aber sagen wir, die main ist ausserhalb und die UIF implementiert nur eine Konsolen variante.
So wird doch die Main ein anderes verhalten bei einer UIF als wie bei einer GUI erfordern, oder nicht?
Die Interfaces der beiden Klassen sind doch eigentlich anders oder?
GUI hätte dann eine Methode "zeigeSplashscreen", welche eine simple UIF auf Konsolenbasis ja nicht besitzt.
Ergo muss doch der Controller auch bei einer UIF anders denken als bei einer GUI.
Bein einer UIF denkt der Controller beim Spielsart : UIF gib mir die Namen, bei einer GUI denkt das Ding aber 1: Zeige bitte das GUI, 2: erzeuge Maske für Namen.
Punkt 1 trifft aber nicht annährend auf UIF zu, weil dort keine GUI vorhanden ist.
Dadurch sind doch beide vom Ablauf grundverschieden.

 

[Roar]

mhm ich versteh was du meinst: zu deinem beispiel: der controller muss nur rumfragen, wie der spieler heißen soll. der rest: dialog anzeigen, blablabla, macht die gui von alleine.
wenn keine gui angezeigt werden soll, wird keine gui angezeigt. der controller kricht nur den namen um das spiel zu starten.

die main() instantiiert höchstens die objekte und startet das spiel, falls das nicht automatisch geschieht. für den rest sind die einzelnen module selbst verantwortlich. einzige ausnahme wör z.b., falls das laden des controllers etc. so lang dauert, dass man besser einen splashscreen anzeigt.

 

[Samuel]

Ja, aber genau darum gehts ja, Beispiel: Wir sollen an einem Projekt arbeiten, welches in der ersten Phase nur eine UIF implementiert und später erst, nach nem Meilenstein des Projekts, wenn das Ding komplett läuft, wird die UIF weggeworfen und die GUI reingesetzt und dennoch geht alles.
Wenn aber in der ersten Phase die UIF so implementiert ist, das nach dem starten des Spiels als erste UIF aktion das eingeben des Spielernamens erforderlich ist, so kann man ja nicht einfach die UIF jetzt wegschmeißen und ne GUI benutzen, weil diese ja zwar die selbe Schnittstelle für Namenseingabe besitzt, aber noch weitere ungenutzte Methoden wie zeigeStartscreen usw.

Ich versuch mal morgen ein Sequenzdiagramm für die beiden Teile zu basteln, vielleicht wirds dann klarer.

Gruß

 

[Samuel]

Aaaah, gestern Abend kam mir noch die Antwort auf meine Fragen, wenn Spiel in der UIF kein zeigeBildschirm vor gibUserNamen aufruft, so tut das Spiel bei GUI auch nicht.
Daher muss man sich schon von vornherein mit einer Interface Klasse beschäftigen, die beide Implementieren, dann haben auch beide eine zeigeBildschirm Methode, welche die UIf einfach nur durch ne Textausgabe implementiert.

Das ist doch die Lösung, oder?

Aber was ist, wenn bei der GUI noch unbekanntte Methoden später auftauchen werden, die man jetzt noch garnicht mitbedacht hat?
Die kann man dann zwar hinzufügen, dürfen aber in der Programmlogik von Spiel keine Rolle spielen, nicht wahr?
Das wären dann irgendwelche Submethoden, die von den Interface Methoden genutzt werden.

 

[AlArenal]

Wenn hinterher was komt, woran man vorher nicht gedacht hat, dann muss man eben mal vorhandenen Code umschreiben. Es ist ein Trugschluss zu denken, man könnte von Beginn an alles einplanen. Macht auch keinen Sinn, wenn man auch mal fertig werden möchte.

Umschreiben und Refactoring gehört dazu.