[SOLVED] Loading an Image only once and using it in multiple objects

I don’t really get your beef with static classes / singletons but stuff like a SpriteBank, in my case a ContentManager shall never ever be instantiated twice.
Your not going to load content twice from file to RAM. And it would be bad if someone did =D

sure Input classes for example don’t need access to this class, but they can’t do any harm really.

My ContentManager is the only class that accesses content/assets in file form directly, and whoever needs content and get it from here.
A centralized class to load, manage and IO content.

Audio is also there, which means, yeah, you can play a sound whenever the inputHandler finds a new device… but it could be that you would actually wanna do this

In any case this access cannot really break anything.

The issues with global mutable state are, as I mentioned, heavily documented so I don’t want to get into it here (and I’ve posted big posts on this board previously if you’re really interested). But I will say that it could be that you don’t see the problems with it because you’re working alone on a small, single person project. You can get away with all sorts of software engineering horrors if it’s just you and the compiler. :slight_smile: If you genuinely have the discipline to get away with that kind of thing then go for it, but I’d rather do things cleanly because it means I’ve got less to think about when I develop and debug.

+1

Also it doesnt matter if you are not doing the work for someone else. When its just you and YOUR project remember its YOUR project. You are the boss. Quite personally I switch back and fourth between singleton and objects. Both of them have their places otherwise one or the other would be missing from java as the language in large.

I came upon an interesting Google Tech Talk video about Singletons* and Global state - and why they are bad. Made me think of this thread so I thougth I’d share it with those interested. Note, it’s a lengthy 50 min video, but Singletons in particular are quite well established at the 30 min mark and a good good question is asked at the 31 min mark!

*I.e. Singletons with private constructors ( like my SpriteBank class ).

watched it.

Obviously when you write APIs/Code other people should use, you gotta do it in a way people will understand.
But in my code, which only I and maybe my team has to understand and use, choose 1 or 2 singletons/static classes when is makes sense, instead of having a gazillion pointers and methods with those parameters…

“These well thought out arguments and points by intelligent people make sense, but somehow don’t apply to me”.

Good luck with that. ::slight_smile:

Also, if you’ve got “a gazillion pointers and parameters”, you’re doing it wrong. This was addressed in the Q&A at the end if you’d actually been paying attention.

I only watched about half of it, but I’m not fully understanding the words he uses (and he speaks so quickly T_T) as English isn’t my native language. I mean, I get why you want to avoid global state, but what was his proposed solution to the problem he was talking about? Factory classes? If someone could explain it really quickly (preferably with some code =S) that would be awesome. I feel like design patterns and the likes are the one thing I need to get better at at the moment. Let’s get this discussion started! =D

There’s very little to understand, and no magic patterns going on. Start at 25:20 to see the fixed version of the code. It’s just removing the singletons and hidden dependancies, and making them explicit by passing required objects as constructor params. You end up with code that’s more explicit, simpler and easier to understand.

The ‘problem’ that most people have is that it’s too simple. They don’t get to point to their code and say “I used four different design patterns here”. It’s not sexy and new and buzzword compliant. But it’s much better code.

If you develop a whole game, you will run into this problem eventually

you dont want all the code in one class, so you split it - but then the other parts depend on parts which are now in other classes
so you either have a lot of pointers or methods which many parameters, which are also pointers

the better your design, the less you encounter this problem

but sometimes you cannot know in advance if and when a class gets too big (unless you have it all planned out) - and then if you split it, you have to look how to do it, so that it is efficient, easy to understand/use and not error prone

I know… It’s hard to figure everything out before you start though, as you basically have to “write” the whole game inside your head…

… which is why I’m kind of stuck at the moment. It’s not like I have a real problem to solve, it’s just that I don’t really dare to continue out of fear of just having to redo everything when I realize the puzzle pieces don’t fit in the end.

[quote]… which is why I’m kind of stuck at the moment. It’s not like I have a real problem to solve, it’s just that I don’t really dare to continue out of fear of just having to redo everything when I realize the puzzle pieces don’t fit in the end.
[/quote]
Hence “agile” programming. ASSUME you will redo/refactor as needs become apparent.

Hence “agile” programming. ASSUME you will redo/refactor as needs become apparent.
[/quote]
But I don’t want to! I want a perfect game after only one try! I want! I want! I want! I want! xD