I'm going to start writing a short series of overviews about the most common Design Patterns from the GoF and the first one I chose to talk about is the Singleton.
Singleton is a creational design pattern that should be used when only one instance of a given object should exist and that instance should be accessible from a global scope.
The classic implementation for a Singleton uses a static member of the Singleton class which is its own instance, a private constructor to ensure that there will be no other way to instantiate other objects and a static public method that returns our instance. This will look a bit like this:
As you can see, the static method that retrieves our Singleton instance will create it if it doesn't exist, and after that return always the same instance. Also, to avoid more than one singleton being created at the same time due to concurrency, we make this method synchronized.
It's important to notice that there should be a single point of access to that object, and that point would be the place where the object creation is managed. Usually it is a getInstance Method, but we could use a Factory to handle that. Below we can see an example of usage for our singleton.
Other Implementations
My favorite implementation for Singletons is the one provided by Joshua Bloch in the book Effective Java. It uses an ENUM, as the way to request an automatically thread safe and simple Singleton. It's a smart way to use this Java native mechanism to produce an object that respects all of a Singleton's needs:
Usage sample:
I find it to be clean and it is also the most recommended way to it.
There's also the eager initialization, that relies on the static initialization of the class to create the class when it's loaded by the class loader, instead of doing it when the getInstance() method is called.
One other famous implementation is the double-lock mechanism for lazy instantiation. It basically replicates the object managed instantiation, but now adding a double synchronization lock to ensure that only one Singleton will be created in a multi-threaded environment.
When to use
Common usages for Singletons are:
- loggers - whenever you want to create a logger object that must be accessible from all components in the system, but should not be re-created every time it's used.
- shared resources - hardware components like printers, input devices, output serial devices, etc can be treated as a singleton in order to manage concurrent access
- configuration classes - configuration and properties are usually unique within a system and referenced by many components. Changes to these properties should also be immediatelly visible to all objects that use it, so this is another use case for our Singletons. In this case, it also serves as a cache, avoiding properties to be reloaded everytime it is accessed.
Issues
Singletons have been widely criticized by the software development industry and a quick search for Singletons are evil will return a good amount on information about why NOT to use singletons. I will enumerated them below, but I particularly believe that the answer to all questions is: "it depends". Even though I agree that singletons are often evil, there are some situations where they might come in handy. The main cons are:
- They're are globally accessible. It means they add state to your entire application and hide dependencies (it's like having a global variable) and at some point that might become hard to manage, debug and maintain.
- If you're using your own class to manage the creation of the Singleton, you'll be breaking the single responsibility principle in your class. Using the Enum technique or a factory to manage your instance could be a solution, but you're still working to do something that feels "unnatural"
- The fact you're hiding dependencies makes things harder to test, and inherently coupled with your singleton. You global state(your singleton) could vary during tests execution for example, producing unpredictable and unreliable results.
