GameState aufräumen

[SKoschnicke]

Die GameState-Klasse ist die erste Klasse die die Schueler ausserhalb der SimpleClient Logik sehen. Das ist sehr unguenstig, wenn das eine andere Sprache ist. Ich werde z.B. als Einfuehrung die getPossibleMoves Methode erklaeren. Das geht aber nicht, wenn die in Kotlin implementiert ist.

Bitte nur die Klassen zu Kotlin konvertieren, wo die Schueler im Zuge der Client-Entwicklung wahrscheinlich nicht reingucken.

[xeruf]

Aber du hast doch selbst gesagt, dass der Sourcecode des Servers "nur für Fortgeschrittene" ist. Vor zwei Jahren hat noch kein Schüler den Sourcecode des gameStates überhaupt zu gesicht bekommen ;) Aber jetzt wo ich darüber nachdenke, solle die getPossibleMoves nicht sogar eher in den SimpleClient?

[SKoschnicke]

Ich denke aber inzwischen, dass die getPossibleMoves Methode sehr nuetzlich ist, um in die Clientprogrammierung reinzukommen. Wenn wir sie verschieben, waere sie vielleicht in der GameRuleLogic gut aufgehoben. Aber GameState sollte weiterhin in Java sein, das ist eine sehr zentrale Klasse.

[xeruf]

Ich denke sowieso, dass all diese Kalkulationsmethoden nicht wirklich in den GameState sondern eher in die GameRuleLogic gehören. In purem Kotlin würde ich daraus Extension Methods machen, aber naja ^^

Ich habe den GameState konvertiert, eben weil er so zentral ist und in Kotlin wesentlich überschaubarer. Hast du Verständnisprobleme beim Code? Ich hatte nämlich bei meinem Umstieg den Eindruck, dass Kotlin auch für Java-Entwickler sehr schnell verständlich ist.

[SKoschnicke]

Nein, ich habe keine Verstaendnisprobleme. Aber wenn ich vor einer Schulklasse sitze, denen ich gerade erklaere, wie man programmiert und die letzte Stunde die Grundlagen von Java beigebracht habe, kann ich nicht auf die getPossibleMoves Methode springen und sagen "das ist jetzt zwar eine andere Programmiersprache aber das versteht man schnell".

Fuer Java-Enwickler ist das nicht schwer, aber unsere Zielgruppe sind Schueler, die weder Programmieren noch Java beherrschen.

[xeruf]

Stimmt. Aber gäbe es denn noch ein Problem, wenn man die getPossibleMoves aus dem gameState rausholt?

[SKoschnicke]

Nein. Da sind allerdings noch andere Methoden, die eher "Spielregeln" sind als "Spielstand". calculateMoveDistance z.B.

[xeruf]

Genau das mein ich. Der einzige Nachteil ist, dass der Code dann mehr verbose wird. Aber ich denke, für die Korrektheit ist das schon sinnvoll. Ich habe nämlich fast das Gefühl, dass wir nicht mal für jedes Jahr einen eigenen GameState brauchen, wenn man das korrekt separiert.

[SKoschnicke]

Klingt gut!

[xeruf]

Die meisten Methoden brauchen auch eigentlich nur das Board, nicht den State. Also verringere ich auch gleich unnötiges coupling, was manchmal nützlich sein kann :D