So, I have a few static classes in my game, where I have a static game, title, and rendering class. But, I don’t see this too often, but it seems pretty nice. Instead of passing a world variable through everything, you could just call it and it’s variables statically. Is there an issue with it? Is using static classes a bad idea? Inefficient? Non-flexible? Or am I just dreaming the whole thing?
Also, static class is just a class with all static variables and methods, to me in my game.
Discussion here.
To summarize, use static when it works. There’s no absolute here. It’s a bit difficult to explain, but look at your examples: Java Math class is static - easy access, just use Math.abs() for example. No need for individual objects because it’s a utility class.
Stack Overflow has some questions that ask when it’s appropriate to use statics.
Where statics have gotten me into trouble is that it is so convenient to make things static that I was creating dependencies where none needed to exist. This made it harder for me to keep things understandable.
… because it is inflexible, bad for dependency management (which is essential for a maintainable software architecture),
bad for testing, a pita to refactor, bad for encapsulation, bad for stateful behaviour, bad for inheritance.
The typical beginner’s usage of static is often an arbitrary mess. Anybody who wants to dive deeper into software architecture, object orientation and Java, understand 3rd party libraries and after all learn his trade should first find out how to set up object relations and communication properly without using static.
Later, when you are a master, you can unlearn all that, and go back to using static where you feel like it.
Cas 
Generally speaking: the only reason static seems like a good idea is because you haven’t looked beyond the scale of your own project.
I recently stumbled on a practical example of statics being a bitch. I was using TableLayout for a Swing app; and at a later point required a hardware-accelerated canvas which I decided to integrate with LibGDX + scene2D UI. The problem is, LibGDX also relies on TableLayout, but the TableLayout uses statics and is therefore singular by design. In the end, I couldn’t smoothly integrate Swing + LibGDX TableLayout into the same application, and had to re-write my own GUI elements for the GL canvas.
With that said, static is obviously a good idea for constants and convenience methods (like Math). Or, if you are just writing your own internal code, and don’t care about its scalability.
The two clues in this post are “your own internal code” and “scale of your own project”.
When you’re right at the top level, making a game (not a library, or even code you’re particularly planning on using in other games), static can help make things much neater.
Cas
I love how cas always writes what I think.
Best practices and good software design are really for 3rd party libraries and stuff.
If you, and maybe just a handful people you know personally are ever going to use that code, and it makes sense, just use static.
Be aware of the problems, but dont let that stop you in your own code if you feel that it makes things easier.
Just use something until it gives you trouble. Until then don’t worry and just code.
I remember talking about static/global state in another (slightly derailed) thread. An explanatory question is asked at the 31:20 timestamp (video). Don’t use static just for kicks. If you don’t know why you’re using static then you shouldn’t use it.
[EDIT]: Oh I forgot to link the actual thread I was talking about and the video in it :V
Thread: http://www.java-gaming.org/topics/loading-multiple-images/24878/msg/212172/view.html#msg212172
That is really a general maxim for any programming construct.
Cas
In my own games I happily ignore a lot of those ‘best practices’:
- Using static methods when it just makes the most sense (typically when one would otherwise write singletons).
- Making fields public (especially final ones) when it makes things more concise.
- Not using unit testing or worrying about ‘test coverage’ (in most cases, test-driven development doesn’t help anyway)
But you do have to be very careful with static fields (which includes enums) if you plan to release on Android.
On the desktop you can be sure that if you start a java program, that classes are initialised (so also its static fields) and that for example static initialisers (as in static {…}) are called.
On Android otoh, you can not rely on that: It will happily reuse classes from a previous run and not call these static initialisers and re-initialise static fields.
Something to keep in mind!