Singleton pattern

Singletons are often preferred to global variables because they do not pollute the global namespace (or their containing namespace). Additionally, they permit lazy allocation and initialization, whereas global variables in many languages will always consume resources.[1][3]

The singleton pattern can also be used as a basis for other design patterns, such as the abstract factory, factory method, builder, and prototype patterns. Facade objects are also often singletons, because only one facade object is required.

Logging is a common real-world use-case for singletons, because all objects which wish to log messages require a uniform point of access and conceptually write to a single source.[4]

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:[5]

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--;
    }
}

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;
    }
}

Critics consider the singleton to be an anti-pattern that introduces global state into an application, often unnecessarily. This introduces a potential dependency on the singleton in all code it is visible to, requiring analysis of implementation details to determine if a dependency actually exists.[6] This increased coupling can introduce difficulties with unit testing.[7] In turn, this places restrictions on any abstraction that uses the singleton, such as preventing concurrent use of multiple instances.[7][8][9][10]

Singletons also violate the single-responsibility principle, because they are responsible for enforcing their own uniqueness, alongside their normal functionality.[7]

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

The Wikibook Computer Science/Design Patterns has a page on the topic of: Singleton implementations in various languages

Wikimedia Commons has media related to Singleton pattern.

• 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)