I hem and haw over these often. Should I use them? Are the necessary? Generally, though, I've come to the conclusion that I need them for Archetype. There are a few components that should not be duplicated in more than once instance. For example, the display class should only be created once. We only need ONE window (and, as far as I can tell, can only create one window), so there should never be any confusion about there being a single one of these objects.
A better argument for my use of singletons, however, is in my events class. I want to be able to access my events class in all objects that need to receive or transmit events, but I want to be able to do it without any object needing to know where to get access to it. So, the question becomes, how do I give my objects access to the global events system, without building into my objects some information about the structure of my engine (and in so doing, causing a breakdown in the reusability of my code)? The singleton has always come to me as the answer to this issue. For each object that needs to send and/or receive events, I can allow them to "create" an event object, send or bind to an event, and I'm done! The beauty of the singleton is, when I "create" an event object, all I'm doing is obtaining a reference to an already existing instance. I make one change to that instance from any object within the game and it's changed system wide! Being that simple, I keep coming back to rely on singletons.
Of course, they also give me a little worry. I haven't even touched threading yet, and there may be some issues that arise when using singletons in a threaded environment. But, for the most part, that's not an issue yet.
So anyway... I've added singletons to the Archetype engine, and, while I've used singletons in other projects, I've come across an implementation which I've been "borrowing" heavily from for my current singleton implementation. For anyone interested, http://www.garyrobinson.net/2004/03/python_singleto.html
[size="4"][RAMBLINGS]
So, ummm... yeah... I'm experimenting with how to organize my journal posts (Yeah... I like the term "journal" over blog). Let's see how this evolves.
GAH! CT is going to get ANOTHER "big storm" in a couple of days. We've got three feet of this white crap in our back yards already... we don't need more! This winter is going to be brutal! If the snow doesn't stop, I'll be spending more time passed out from shoveling than I will be sitting here working on my engine! *Takes a deeeeeep breath*
HEY! I'd also like to thank everyone who's commented so far, and who's been reading my journal. Hope it's been worth the read for you all!!
1.) If you only need one display class and one window.... only create one of each. The singleton pattern states that it is an object that is only created once AND global access is needed. Does your sound system need access to the window... or the display class? Usually having these as singletons just creates spaghetti-like access from various classes when a design issue creeps up (and it will), rather than sitting and thinking through the design and reworking some things most people will just call the singleton and "change it later".
2.) The worst thing you can have when dealing with threaded systems are global static variables, they are an extreme no-no. So I would really suggest thinking over how to architect your system without using global static variables, as this completely blows up threading/concurrency and you *will* have to rewrite it.