Wednesday, 16 January 2008

Should Singletons be avoided?

First of all, happy new year all. I've been busy and not had much time to blog recently and not seen too much on the web to really get my teeth into. Until I found this...

According to an article in the Software Development Times many developers are thinking that Singletons are bad and should be avoided. I was wondering, why, exactly? In some ways it may be because using them as houses to store global varaibles (a use I often put them to myself) may be considered bad in the same way that globals are bad. The author comments on Singletons being bad for unit testing, but I tend to find the opposite is true myself. With global variables, you have to have access to whatever code sets up their defaults or any code that uses them will fall flat on itself when used in isolation of the main project. With a Singleton, those values are set up to their default values when the instance is requested for the first time, which it will be with a class that is being tested outside of the main project. So I'm left wondering, why would there be a backlash against Singletons as a design pattern? Is it that developers are struggling with OOP concepts (especially design patterns) and frequently misuse them?


Gabriel Ware said...


There are a few reasons you didn't named explaining why developpers are making so much fuss over singleton.

First, by using singleton you are coupling your class/methods/functions with other class without explicitly saying so. Thus your objects interfaces are tainted.

Second point is about the lifetime of singletons. Why would you want to create something when it's first accessed ? That means you don't know when it is created (or at least it's not explicit) and that it can be created at the worst time. Also, When do you end the life of a singleton object? Since you don't know when it starts, it's a bit hard to determine when it finishes (meaning that if your singleton is allocating memory, you end up fragmenting a bit ...).
This whole point could be rejected because singleton are defined by "classes that should be instanciated only once" and, AFAIK, nothing dictates the way they are actually created. But since most programmers instantiate them at first use I think this point is relevant enough to be stated.

About unit testing, the problem is states. When several tests are run, it acceptable to think they have been pack'd in a test suite and will be run in a single execution.
The problem with singleton in that case is that they are persistant and they may have an internal state. You have to be very careful about your tests because of this internal state. You may need to "restart" your singleton (and again, another developper won't necessarily know this because the use of this class isn't in your prototypes).

Still, they are very useful in practice :) But as a design pattern there are practical drawbacks one shouldn't ignore.


The Recursion King said...

I'm relating this to Actionscript as that is the technology I'm currently using for development. Actionscript, like many languages, connects classes together through import statements. So addressing your first, point, the relationship is explicit because you must import the singleton class into your custom class in order to access it. It is not globally available implicitly. So, certainly for Actionscript (and other technologies too), it is an explicit declaration that your class will be using the singleton class.

Good second point though. If developers are using large amounts of memory or cpu intensive code in a singleton (all possible, nothing inherently restricts you from doing this except good programming practices generally - but you can't bank on common sense winning the day) then you could have a problem.

It's good to have another perspective on this to see the potential downsides.