Now, this isn't a recent topic, and it's actually been on my mind for a long time now. But, I think that I should probably clarify my feelings towards this particularly virulent infection that seems to spread like wildfire amongst lesser beings (that would be you [grin]).
Definition of Singleton
The singleton pattern is defined as a means to "ensure a class has one instance, and provide a global point of access to it"
[DP, 127]. Essentially, you have restricted the creation of the class to a single point in the code. For most implementations, that point will also provide the global access to the singleton.
The Great Disease: Singletonitis
So, what is Singletonitis? It's a disease discovered by one Joshua Kerievsky. He enumerated his discovery in his book Refactoring To Patterns. To summarize, it is when a person becomes addicted to the Singleton pattern.
Unfortunately, this disease is easily spread amongst the untrained. It those infected with this disease take many months or years to be cured, and many will be infected for life. Because of this, we urge you to avoid singletons at all cost. Think of all of those poor unfortunate newbies you will be saving from a tragic demise.
Candidates for Singletons
Graphics Manager
- Why: I need to use my Graphics object all over my code, and I only need one Graphics object.
- Response: No, you don't. You need to use your Graphics object in a small amount of code that is scattered all over the place due to a failure to properly refactor and design. Should you apply the appropriate refactorings and design methodologies, you will find that a singleton is not needed. Further more, if you don't need more than one graphics object, don't create more than one.
Sound Manager
- Why: For much the same reason as the Graphics object, code all over the place uses it, and I only need a single instance of it.
- Response: Much the same as the Graphics object, proper refactoring and design techniques will consolidate the (much duplicated) code required to deal with the sound manager to a small number of classes. Hence eliminating the need for a singleton.
Input Manager
- Why: Because I'm a retard.
- Response: If you're using a singleton for your input manager then you have a big problem. Specifically, the amount of code that ever needs to access the input manager is about...1 method. Maybe more than one depending on what refactorings you apply. But it does not need to be accessed by more than one class. In fact, it shouldn't be accessed by anyone but perhaps an action map class. Which also doesn't need to be a singleton, since it will in turn only be accessed by a very small number of classes.
The list goes on. For almost all of the cases, the reasoning behind why they need a singleton is that it would either be: "to hard" to pass a pointer around, or they only need a single instance. Neither of which is a valid reason to use a singleton. Proper refactorings can eliminate the majority of deep pointer passings that are required in order to get an object to where it needs to go. Furthermore it will properly centralize common code and allow the removal of a great deal of duplication. As for the single instance excuse: So? Only create one instance then. If you are going to be passing this on to someone else then either properly document it, or use a factory, which could be a singleton (doesn't have to be, heck it could be a monostate (note that I didn't say that it has to be either of those.)).
Fruny loves singletons. They are his favorite thing to code in his favorite language, Pythong. He also likes to use them in C++ for fixing the order of initialization of static instances. This is an abuse of singletons, and is NOT REQUIRED. But how can I get around it you say? Simple: Don't have a global that depends upon another global, if you do then chances are that you have a serious design flaw, and should refactor it out.
