Singleton pattern

A class diagram exemplifying the singleton pattern.

In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to a singular instance. One of the well-known "Gang of Four" design patterns, which describe how to solve recurring problems in object-oriented software, the pattern is useful when exactly one object is needed to coordinate actions across a system.

More specifically, the singleton pattern allows objects to:

• Ensure they only have one instance
• Provide easy access to that instance
• Control their instantiation (for example, hiding the constructors of a class)

The term comes from the mathematical concept of a singleton.

Common uses

• The abstract factory, factory method, builder, and prototype patterns can use singletons.
• Facade objects are often singletons because only one facade object is required.
• State objects are often singletons.
• Singletons are often preferred to global variables because:
  • They do not pollute the global namespace (or, in languages with nested namespaces, their containing namespace) with unnecessary variables.
  • They permit lazy allocation and initialization, whereas global variables in many languages will always consume resources.

Logging is a classic example of a singleton.

Criticism

Critics consider the singleton to be an anti-pattern as it introduces global state into an application, often unnecessarily. This in turn can place restrictions on any abstraction that uses the singleton, for example by preventing concurrent use of multiple instances. Furthermore, because it is often exposed as a globally visible accessor, its presence complicates dependency analysis by introducing a potential dependency on the singleton in all code it is visible to, thus requiring analysis of implementation details to determine if a dependency actually exists.

Singletons also violate the single-responsibility principle, because not only are they responsible for the singleton's normal task, it must also ensure that only one is instantiated; note that this relies on a "classic" singleton definition where it is responsible for enforcing its own uniqueness through, for example, a static getInstance() method.

Another drawback is that singletons are difficult to test because they carry global state for the duration of the program . Specifically, because unit testing requires loosely coupled classes in order to isolate what's being tested. Additionally, when a certain class interacts with a singleton, that class and the singleton become tightly coupled , making it impossible to test the class on its own without also testing the singleton .

Implementations

Implementations of the singleton pattern ensure that only one instance of the singleton class ever exists, and typically provide global access to that instance.

Typically, this is done by:

• Declaring all constructors of the class to be private, which prevents it from being instantiated by other objects
• Providing a static method that returns a reference to the instance

The instance is usually stored as a private static variable; the instance is created when the variable is initialized, at some point before the static method is first called.

The following snippet provides an example implementation, written in Java:

public class Coin {

    private static final int ADD_MORE_COIN = 10;
    private int coin;
    private static Coin instance = new Coin(); // eagerly loads the singleton

    private Coin() {
        // private to prevent anyone else from instantiating
    }

    public static Coin getInstance() {
        return instance;
    }

    public int getCoin() {
        return coin;
    }

    public void addMoreCoin() {
        coin += ADD_MORE_COIN;
    }

    public void deductCoin() {
        coin--;
    }
}

Lazy initialization

A singleton implementation may use lazy initialization, where the instance is created when the static method is first invoked. In multi-threaded programs, this can cause race conditions that result in the creation of multiple instances. The following is a thread-safe implementation, using lazy initialization with double-checked locking, written in Java.

public class Singleton {

    private static volatile Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized(Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }

        return instance;
    }
}

See also

• Initialization-on-demand holder idiom
• Multiton pattern
• Software design pattern

External links

• Complete article "Java Singleton Pattern Explained"
• Four different ways to implement singleton in Java "Ways to implement singleton in Java"
• Book extract: Implementing the Singleton Pattern in C# by Jon Skeet
• Singleton at Microsoft patterns & practices Developer Center
• IBM article "Double-checked locking and the Singleton pattern" by Peter Haggar
• Geary, David (April 25, 2003). "How to navigate the deceptively simple Singleton pattern". Java Design Patterns. JavaWorld. Retrieved 2020-07-21.
• Google Singleton Detector (analyzes Java bytecode to detect singletons)