This might be bad form, but I've got my project split out into gamestates (with three of those as different areas) and I want to keep track of game statistics, player info, and other data-oriented "state" info that doesn't belong hardcoded in any of the gamestates. How does one go about creating one object at startup and then access it from any state or class that might be active in the game? The uses for this object's methods and data would be for such things like player health, inventory, non-random enemies that belong to specific maps (that must be trackable from saved game to saved game), manipulated models that have various states that need to be preserved between saved games (openable chests, door, and movable items) or between gamestate changes.
Any help (or other ideas on how to do this) would be greatly appreciated!
You can create some Manager classes, who manage access to those resources.
Such classes are often implemented as Singletons, so that you can access them from anywhere.
In this wiki entry, the Values class is a Singleton, to share Data between the GUI and Game Gamestate.
Read up on the Singleton Design Pattern if you’re not familiar with it yet.
Beautiful! Thanks! I was wondering what those Singletons were all about!
I also found this article to be ultra helpful: Introducing the singleton - "The Single Java Object"
Singletons are a good start but thez are considered bad coding style (don't hit me, I am using them myself but only very careful).
If you are using only one singleton it's ok but when you start having more than 3 in your app you should probably consider to implement a registry and do it interface based.
pflanzenmoerder said:
but thez are considered bad coding style
By some people. Not all. The most cited alternative to Singletons is Dependency Injection, and there are just as many reasons to not like DI as there are to not like Singletons.
I don't mean to start an endless discussion about Singletons vs DI Factories here, but I think a statement like "Singletons are considered bad coding style" just needs a bit more context.
Context:
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=004232
even more context:
http://lambda-the-ultimate.org/node/1219
I am not talking about replacing singletons with DI.
DI is one of the alternatives I am using but the most common one that is actually used is to have ONE manager singleton that manages instances of other classes.
Reason:
Singletons are not easily mockable and replaceable as you always have to use the concrete class and not something based on an interface.
And yes I still considere singletons bad style as I consider it bad (if there are ways to avoid it) to code to a concrete class and not to an interface.
Back on subject here.
You need a cache of instance objects, a collection or whatever appropriate mechanism meets your needs.
btw, you dont need to synchronize the method getInstance in your singleton if you know your application and it is running in a controlled environment. Just call getInstance early on so that there is only one instance and ensure there will be no race condition.