spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich würde ein EnumRegistry-Interface bauen. Jede Profession ist gleichzeitig auch ein Typ und implementiert dazu ein Interface.
interface PseudoEnum {
String name();
}

Dann kannst Du solche Methoden in der Registry einbauen:
<T extends PseudoEnum> Set<T> getEnumValues( Class<T> pseudoEnumInterface )
<T extends PseudoEnum> T resolveEnumName( String enumValueName, Class<T> pseudoEnumInterface )
<T extends PseudoEnum> void register( Class<T> pseudoEnumInterface, T enumValue )

Jetzt haben wir immer noch das Problem des statischen Zugriffs. Das kann man ganz ok über einen Context lösen. Dieser kann, wenn es sonst zu unpraktisch ist, per ThreadLocal zugänglich sein.
class GameContext {
EnumRegistry getEnumRegistry()
AssetManager getAsssetManager()
...
}

GameContext.get().getEnumRegistry()....
oder mit statischen Platzhaltern, die das ganze verschleiern dann:
GameContext.getEnumRegistry()


Wenn Du's per ThreadLocal machst, kannst Du relativ elegant den ganzen Stress mit GameContext rumreichen sparen. Wenn Du es richtig robust machen willst, kannst Du den GameContext AutoCloseable machen. Erzeugt man sich wie auch immer einen GameContext wird er in einen Stack in einer ThreadLocal geschrieben. Wenn er geschlossen wird, wird auch der Stack gepoppt. Schon kannst Du sogar in einem Thread mehrere GameContexte übereinander legen und recht robust verwenden. Beim Starten von Runnables in anderen Threads müsstest Du noch überlegen, wie Du dort den GameContext rüberbekommst, aber das ist ja keine Raketentechnik. Pass bei der Implementierung ein bisschen auf: https://plumbr.io/blog/locked-threads/ho…th-threadlocals

Viele größere Frameworks und Bibliotheken nutzen so ein Context-ThreadLocal-Pattern, um Aufrufketten in einen Kontext zu bringen ohne dass die gesamte Anwendung dann in diesem Kontext läuft. Von Transaktionen und EntityManagern bis Service-Registries wird so ein bisschen "by magic" Zeug rumgereicht, ohne dass es als Parameter übergeben wird.

Boar, echt jetzt? Bin ich der Einzige, der die Lösungsvorschläge immer gruseliger findet?

Nein, bist du nicht

Finde ich überhaupt nicht. Man braucht bei Spielen meist X Singleton-artige Dienste. Entweder man reicht die Referenzen immer durch, man hinterlegt die als Singleton, man nutzt Dependency-Injection oder man baut sich ein Context-Object. Das muss man aber überall durchreichen, oder man nimmt halt ein ThreadLocal-Konstrukt um den Kontext durch die verschiedenen Ebenen zu bringen. Ziemlich viele Frameworks machen das so oder so ähnlich. Hier mal ein Beispiel aus dem Activiti-BPM-Projekt: https://github.com/Activiti/Activiti/blo…xt/Context.java Spiele sind ähnlich krakenartig, was den Informationsbedarf zwischen einzelnen Komponenten angeht. Und man möchte meist auch an vielen Stellen gar nicht wissen, was alles gerade vorgeht.

Zitat von »damios«

@BlueCobold Das ist ein nettes Beispiel, aber was das mit meinem Problem zu tun haben soll, ist mir leider völlig schleierhaft.

Das ist natürlich sehr traurig. Fällt dir keine "Is-a" Relation in Bezug auf Programmierung ein?

Zitat von »Chromanoid«

Finde ich überhaupt nicht. Man braucht bei Spielen meist X Singleton-artige Dienste. Entweder man reicht die Referenzen immer durch, man hinterlegt die als Singleton, man nutzt Dependency-Injection oder man baut sich ein Context-Object. Das muss man aber überall durchreichen, oder man nimmt halt ein ThreadLocal-Konstrukt um den Kontext durch die verschiedenen Ebenen zu bringen.

In Sprachen wo es Frameworks zur Automatisierung von DI gibt würde ich nichts anderes wählen. Kein Durchreichen, identisches Vorgehen bei Singleton und nicht Singleton, zentral konfiguriert und problemlos beim Testen.

Zitat von »Tobiking«

Zitat von »Chromanoid«

Finde ich überhaupt nicht. Man braucht bei Spielen meist X Singleton-artige Dienste. Entweder man reicht die Referenzen immer durch, man hinterlegt die als Singleton, man nutzt Dependency-Injection oder man baut sich ein Context-Object. Das muss man aber überall durchreichen, oder man nimmt halt ein ThreadLocal-Konstrukt um den Kontext durch die verschiedenen Ebenen zu bringen.

In Sprachen wo es Frameworks zur Automatisierung von DI gibt würde ich nichts anderes wählen. Kein Durchreichen, identisches Vorgehen bei Singleton und nicht Singleton, zentral konfiguriert und problemlos beim Testen.

Na da gibt's ja 1001 Framework in Java, oder was meinst Du? Damit das ganze auch schön auf Android läuft usw. würde ich in diesem Fall vielleicht https://google.github.io/dagger/ empfehlen. Ansonsten fand ich Guice auch sehr schön.

Wir reden hier schon noch über ein recht einfaches Thema von primitiven Daten, die eine hierarchische Vererbungsstruktur aufweisen, ja?

Bevor wir klären, wie der TE also an seine Daten heran kommt, sollten wir vielleicht mal klären, wo er meint dieses überhaupt überall zu brauchen und auf welche Art und Weise. Mir hängt die ganze Zeit so ein übler Geruch von schlecht strukturiertem Code in der Nase und wenn ich die Ideen anschaue, wie man die Daten abbilden könnte, wird das ganze echt nicht besser. Es geht hier erstmal nur um eine Menge von Berufen, von denen jeder seine eigenen Eigenschaften hat. Das ist aus meiner Sicht ein absolut klassisches Beispiel von Vererbung. Und ob er auf diese Daten wirklich zentral injektiert an tausend Stellen zugreifen muss, halte ich erst mal für sehr fraglich.

Ich werde im Moment den Eindruck von Overengineering einfach nicht los.

Wenn ich das richtig sehe, gibt es keine eigenen Klassen je Beruf. Es gibt eine Berufstypklasse und eine Berufsklasse, die Berufstyp und die Erfahrung darin zuordnet.

Wenn ich das Problem richtig verstehe, geht es darum in einer Datei gespeicherte Werte zu laden und allen Teilen des Programms zur Verfügung zu stellen. Das wurde bisher über statische Variablen gelöst - die machen aber Ärger beim Test-Schreiben.