Macht die Modellierung der Systeme als eigene Klassen Sinn?

[cagix]

aus #1587 (comment):

Mittelfristig sollten wir nochmal drüber nachdenken, ob diese "fetten" Systeme so wirklich Sinn ergeben. Letztlich ist ein System i.d.R. nur eine zustandslose Funktion, die im Game registriert und dann zyklisch ausgeführt wird. Warum sollte ich dafür jeweils eine extra Klasse formulieren (müssen)? @AMatutat

Edit: Die Klasse System könnte diese Funktionen wie eine Factory-Klasse über statische Hilfsmethoden "produzieren", d.h. man hätte einen Ort (Klasse System) und einen Namen (Factory-Method), um an diese Callbacks dran zukommen für die Registrierung im Game.

Jedes System hat aktuell eine eigene Klasse. Durch die Vielzahl der Systeme hat man eine entsprechende Vielzahl an Einträgen im Package-Tree. Muss das wirklich so? Würde es nicht reichen, beispielsweise in System pro System eine Art "Factory"-Methode zu haben, die die jeweilige System-Funktion (aktuell als execute-Methode implementiert) als Function<Void,Void> zurückliefert?

Das Pausieren der Systeme müsste außerhalb der Systeme passieren. Das ist an sich ja auch keine Eigenschaft der Systeme, sondern des Game. Systeme selbst sind rein passive Funktionen (aktuell Funktionsobjekte) und werden von Game aufgerufen, wenn es Game in den Kram passt - warum sollte ein System dann wissen, ob es grad pausiert ist?

Potentielle Vorteile:

• Deutlich mentaler Clutter
  • weniger Klassen => weniger Einträge im Package-Tree
  • weniger Boiler-Plate-Code
• Alle Funktionen vereint in der Klasse System (über passende Methodenaufrufe) (ggf. ist System dann sogar nur ein Interface?)
• Jedes System sollte es nur exakt einmal in Game geben dürfen - die Modellierung als Funktion unterstützt diesen Gedanken (die System-Klassen müssten eigentlich jeweils Singletons sein)

Potentielle Nachteile:

• Framework-Gedanke: Wo schreiben die "Kunden" ihre eigenen Systems hin? Gibt das dann Wildwuchs? (Idee: Die könnten in ihrem eigenen Package ebenfalls eine Klasse System haben mit ihren eigenen Funktionen ...)
• Was ist, wenn ein System dann doch mal zustandsbehaftet sein soll?

Edit: Gute Startpunkte für eine zusätzliche Recherche könnten Dominion (Java-ECS) und die ECS FAQ (via FLECS) sein.

[AMatutat]

Die Frage finde ich gut.

Darüber liegt für mich aber noch die Frage, wofür ist das Dungeon Framework noch gedacht? Ursprünglich wollten wir damit Java UND OOP vertiefen. Das spricht für mehr OOP und weniger Funktional.
Mittlerweile ist der Fokuspunkt aber verschoben, oder?

[cagix]

Die Frage finde ich gut.

Darüber liegt für mich aber noch die Frage, wofür ist das Dungeon Framework noch gedacht? Ursprünglich wollten wir damit Java UND OOP vertiefen. Das spricht für mehr OOP und weniger Funktional. Mittlerweile ist der Fokuspunkt aber verschoben, oder?

@AMatutat Fokus verschoben weiss ich nicht. Es geht immer noch um eine Programmierausbildung auf einem fortgeschrittenen Level mit/in einer OO-Programmiersprache und um diverse Programmiermethoden (oder DevOps, wenn Du das so nennen wolltest).

Es ist halt nur so, dass nach der "langen Dürre der OO-Zeit" sich nun endlich "Regen am Horizont" abzeichnet und die Welt wieder vernünftiger wird und funktionale Konzepte (wieder) als sinnvoll erkennt, und das natürlich auch in Sprachen wie Java reinsickert.

Im Grunde mache ich immer noch objektorientierte Programmierung, aber mit funktionalem Touch (wo es sinnvoll ist - verbesserte Abstraktion, Lesbarkeit, Wartbarkeit, ...). So richtig viel geht da in Java ja sowieso nicht wirklich, und ziemlich viele Dinge sind extrem ... hässlich umgesetzt. Aber die Denkmuster ändern sich an einigen Stellen doch deutlich :)

Insofern würde ich nicht den Weg zurück zum ersten Dungeon gehen wollen (rein OO). Wir haben eine Mischform (Objektorientierte Programmierung, Funktionale Programmierung, Daten-orientierte Programmierung), und das ist auch gut so. Mein Ziel ist nur, den Zuschnitt weiter zu schärfen und die Modellierung sowie die Nutzbarkeit zu verbessern, also beispielsweise nicht unbedingt notwendigen mentalen Ballast über Bord zu werfen oder bestimmte Konzepte nochmal im Rückspiegel zu betrachten und ggf. zu korrigieren.