Singleton Design Pattern
Ensure a class has only one instance and provide a global point of access to it. (dofactory)
- Singleton defines an Instance operation that lets clients access its unique instance. Instance is a class operation and responsible for creating and maintaining its own unique instance.
- When you need to ensure there is one instance of an object, available to a number of other classes, you may want to use the Singleton pattern. Singletons are used a lot where you need to provide a registry, or something like a thread pool. Logging is also another popular use of Singletons, providing one single access point to an applications log file.
- Singleton should be considered only if all three of the following criteria are satisfied:
- Ownership of the single instance cannot be reasonably assigned
- Lazy initialization is desirable
- Global access is not otherwise provided for
- Encapsulated “just-in-time initialization” or “initialization on first use”.
- Ensure a class has only one instance, and provide a global point of access to it.
- The advantage of Singleton over global variables is that you are absolutely sure of the number of instances when you use Singleton, and, you can change your mind and manage any number of instances.
- A special care should be taken when singleton has to be used in a multithreading application.
- Using global state are very difficult to test.
- Programs that rely on global state hide their dependencies.
- Singleton user and the singleton become inextricably coupled together.
- The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less. Designers frequently use Singletons in a misguided attempt to replace global variables. A Singleton is, for intents and purposes, a global variable. The Singleton does not do away with the global; it merely renames it.
- Singleton is infamous in object oriented systems. A lot of the time the Singleton is used as a shortcut, so that the designer doesn't need to think properly about object visibility. If you're hacking in a Singleton so that there is global access to a resource, maybe it's not the right thing to do. It might be better to work out how to pass the reference to that resource around properly.
- Another important consideration is multi-threading. If two threads call the Instance() method at the same time, you can end up with two singletons. Making the Instance() method synchronized solves this issue, but then you have the performance cost - calling a synchronized version of Instance() will be slower than the non-synchronized version. However, maybe the best way around this is to sacrifice lazy-loading in the Singleton, ensuring there can only ever be on instance.
- When is Singleton unnecessary? Short answer: most of the time. Long answer: when it’s simpler to pass an object resource as a reference to the objects that need it, rather than letting objects access the resource globally. The real problem with Singletons is that they give you such a good excuse not to think carefully about the appropriate visibility of an object. Finding the right balance of exposure and protection for an object is critical for maintaining flexibility.
Singleton pattern using double-checked locking example
Singleton pattern using .NET Lazy<T> example
- Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
- Facade objects are often Singletons because only one Facade object is required.
- State objects are often Singletons.