The Singleton design pattern

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|376\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Article Home -> Advanced Techniques

Phoenix	Created : 01 June 2007 The Singleton design pattern A hated and loved design pattern
Introduction: What is it? A singleton is a class which can only have one global instance of itself. This design is implementable many languages, but not in Blitz, due to it's types being limited. This design pattern is often considered a bad design choice, and a quick search on the net shows why. However, it is ver popular and good to know how to use. It doesn't mean instant failure, games like Hero of Allacrost uses it, and they seem to be progressing quite well. But, it is up to you if you want to use it. How is it accomplished? It is quite easy actually, here is some small code in C# to demonstrate it. public class DebugLogger { // The member keeping track of our instance private static DebugLogger singletonInstance; // Private constructor private DebugLogger() { } // Static makes it possible to call it like this: DebugLogger.GetSingleton() // as opposed to: // DebugLogger myLog = new DebugLogger(); // myLog.GetSingleton(); public static DebugLogger GetSingleton() { // Check if we already have an instance If( singletonInstance == null ) { singletonInstance = new DebugLogger(); } return singletonInstance; } } --v The above code makes the constructor private, which means that you can't create an instance of it from outside the class. The next interesting thing is the GetSingleton() method, which is defined as static. This is so that we should be able to call it without creating an instance of it. If we call it, it will store a DebugLogger in our singletonInstance, unless it already exists. The created DebugLogger is stored in our static singletonInstance. If our debug logger had a method called Log, to use it we would only do this: DebugLogger.GetSingleton().Log() --v Since GetSingleton() always returns a DebugLogger, which is always the same one, you can store all kinds of members and methods in it, and it will act like a normal class. Many people create their game engines as singletons: while( CoreEngine.GetSingleton().IsRunning() ) { VideoEngine.GetSingleton().UpdateScreen(); SoundManager.GetSingleton().PlaySound( "bark.wav" ); } --v Conclusion I hope that made any sense Cause I'm not sure if I wrote too little/much, so ask any questions below.

Comments
Friday, 01 June 2007, 10:18
JL235	I can already think of lots of answers to this, but your article didn't touch on it at all (which maybe it could have). What are the advantages of using this singleton design instead of a fully static class? i.e. by making all those instance methods static, your code above could be: while( CoreEngine.IsRunning() ) { VideoEngine.UpdateScreen(); SoundManager.PlaySound( "bark.wav" ); } --v Still, although I've known about this method I've never really used it. After reading this, next time I'm thinking of making a fully static class (and I cannot) I might give this a thought as an alternative.
Friday, 01 June 2007, 12:22
JL235	Actually, scrap that. I've just realised all the advantages I thought of, namely about being able to store and pass around the singleton, are pointless if it's global. I cannot think of a single advantage of a singleton over a static class.
Friday, 01 June 2007, 15:29
Phoenix	Me neither, I never use them. Static classes and singletons are almost the same, however it could be good to know what they are.
Thursday, 23 August 2007, 01:21
JL235	I've finally gotten around to reading the end of Objects First with Java. Shockingly enough it suggests singletons as a design pattern people could use. I'm a little disappointed. Anywho, there is better way you could implement your code. Rather then checking if it's null you could make the singleton on start up. public class DebugLogger { // The member keeping track of our instance private static DebugLogger singletonInstance = new DebugLogger(); // Private constructor private DebugLogger() { } // Static makes it possible to call it like this: DebugLogger.GetSingleton() // as opposed to: // DebugLogger myLog = new DebugLogger(); // myLog.GetSingleton(); public static DebugLogger GetSingleton() { return singletonInstance; } } --v Even then, why not just make it final and public too. Then you can avoid the whole get method too, and it'd just be a constant. That'd get rid of the whole singleton idea.

The Singleton design pattern

Comments