This will be a part of a series of posts about some design patterns that I have found more or less useful, when developing this small page, or just in general programming. So to start it all off – what is a design pattern? To put it briefly – a design pattern is a general (abstract) solution to common situations encountered in software design. It's not a finished implementation but a template for solving problems without specifying the implementation.
What is it?
The first one we'll cover is the Singleton Pattern, which is probably the simplest design pattern to understand and implement. It is used to restrict the initialization of a class to only one object and provide a global point of access for that object. The implementation of the singleton pattern requires a method that returns the singleton object if it's already created or a reference to the singleton object created earlier.
A simple implementation (not thread-safe) could look something like this, in an unnamed object oriented programming language:
class Singleton {
static Singleton instance;
//Private constructor.
private Singleton()
public getInstance(){
if(instance)
return this.instance;
else{
this.instance = new Singleton();
return this.instance;
}
}
}
And why not?
Unit testing
Singeltons are in essence not very different from a global variable and as such it carries around a state, a state that will change depending on how the program is being executed. This might not seem like a problem under normal use but for unit testing it's a big no no. Unit testing is effective because the tests are independent of each-other and since this is not true with global states the order in which the tests are performed will change their outcome. Another problem is that singletons are by nature tightly coupled to the classes that depends on them meaning that mocking or injecting a subclass of the singleton is non-trivial.
Hidden dependencies
Singletons also have the somewhat annoying tendency to hide dependencies in the API. When a class instantiates or gets a class via a singleton it's really just silently accessing a global variable that influences it's behavior. It means that you can't just examine a classes interface to understand it's dependencies, you have to wade through the actual source. Singletons are easily abused as a means of not having to pass around references to services.
Single responsibility
While you can limit the instantiation of a singleton to only one object. But why should this be the responsibility of the singleton itself? If an application only needs one instance of an object it should make sure to enforce that requirement itself, having the singleton do it breaks the Single Responsibility Principle and makes the class less general – what happens if you suddenly find out that you need two or more instances of a class in the program?
Memory Handling
A singleton has the advantage it can be lazily instantiated it also carries the big disadvantage that there is no simple way of garbage collecting the object if it's not going to be used for a while, or again. And since you don't really know for sure if it will be used or not it will be hanging around until the end of the application.
It can seem like a good way to make sure that it's resources are properly terminated when the program closes this can't be guaranteed either if the program exits in a non-controlled way. Not to mention the fact that the resource will be open all the time.
Extensibility
Extending singletons is not a trivial matter either since static methods aren't very flexible at all. So the day that you wake up to find out that you actually need subclasses of the singleton you just made yourself a bigger problem than you had too. This might however be a smaller issue if the singleton is actually a class created by a factory.
Conclusion
The singleton is a quite common pattern and why is that really? Well, because they feel warm and fuzzy to use. Let's face it, using design patterns actually feels somewhat good, you are doing something that's supposed to be more or less right, like following a recipe, and this one in particular is very use to understand and implement. Not to mention it can make your code look cleaner. Hell, I use them for quick and dirty little things I do for myself, things that I know no-one else will ever need to test or maintain.
So to finish it all off – Singletons are global variables and as such they carry with them some problems that might or not be an issue for you. In general they are simply an excuse not to pass around dependents. If you really need a singleton object then creating it at the top of your application and passing it down is probably a better solution. Add in a factory and you can get the exact same behavior without much of the drawback.
So why did I really go through all this just to tell you that the singleton pattern is crap, well because there really can be situations where they are usable. If passing around a lot of services isn't feasible (though restructuring your code can be an option), if you will need one and only one instance of the class – or rather when instancing the class multiple times can actually be harmful.