Jump to content
  • Advertisement
  • entries
  • comments
  • views

Why are you infected with Singletonitis?

Sign in to follow this  


Why are you infected with Singletonitis?
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.
Sign in to follow this  


Recommended Comments

I suffer from this affliction myself. It also gets especially terrible when I'm working in C#'s pure O.O. and managed environment. Then again, is it wrong to use singletons in C#? The language seems to be designed to encourage this type of programming.

Share this comment

Link to comment
I used to use singletons. But then I got tired of Washu cruelly mocking me all the time and calling me names in #gamedev. So I stopped. [grin]

Share this comment

Link to comment
I'm cured from Singletons. Especially since i discovered the hard way (at work) that Singletons caused some problems in the long term.

To be more precise, like many people, i started an engine, thinking "hell, i'll never need more than one renderer. Let's make a Singleton". One hundred thousand lines later, a customer wants support for workstations with multiple graphics cards. Suddenly, i need many renderers, and my code is not designed for it. Lots of effort and countless hours/bugs to fix it.

That was a few years ago. Since then, i never, ever, ever use Singletons. Actually i'd be surprized if there's even one of them in my code. I tell you, Singletons are the Devil. There will always be cases where your Unique instance no longer needs to be unique.


Share this comment

Link to comment
I happen to know that Washu is planning to discuss the root causes of Singletonitis in the next journal update, in case anyone was wondering.

Share this comment

Link to comment
I never started using Singletons; I prefer redundant pointer passing. Seriously. Because polymorphism kicks my ass.

Share this comment

Link to comment
Guest Anonymous Poster


In your article you didn't mention why singletons aren’t good (with very few exceptions) so I guess I will state those things.

1. Memory management is a big problem. If you aren’t careful on how you set up your singleton you basically have a memory leak until you decide to kill the singleton. This is the case when you have a singleton that isn’t used much; you have a good chance of wasting resources when in fact you don’t need those resources in a given situation. Basically, it’s hard to safely delete a singleton, and singletons don’t deal well with deletion.
2. The classic singleton pattern isn’t thread-safe, and singletons that fix that are expensive from that point of view. This wasn’t an issue in the past for most people writing games and such, but it is a huge problem now that we have multiple cores and such.
3. Unit testing when using singletons is just plain horrible due to the coupling between classes caused by the use of singletons.
4. You are hiding complexity with the pattern so people end up over using it.
5. Given the global nature of the access to a singleton, writing code that very modular and concise is hard since you are able to call the singleton from anywhere.
6. The global nature of the singletons break the object oriented paradigm by breaking the encapsulation. This is just as bad as having global variables.
7. Singletons by themselves don’t support polymorphism.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!