Singleton

Lets you ensure that a class has only one instance, while providing a global access point to this instance.

classDiagram
    class Singleton {
        -static Singleton instance
        -Singleton()
        +static getInstance() Singleton
    }

When to use

Use the Singleton pattern when a class in your program should have just a single instance available to all clients; for example, a single database object shared by different parts of the program. Use when you need stricter control over global variables.

Explanation

Problem

The Singleton pattern solves two problems at the same time, violating the Single Responsibility Principle:

Ensure that a class has just a single instance. Why would anyone want to control how many instances of a class a class has? The most common reason for this is to control access to some shared resource—for example, a database or a file.
Provide a global access point to that instance. Just like a global variable, the Singleton pattern lets you access some object from anywhere in the program. However, it also protects that instance from being overwritten by other code.

Solution

All implementations of the Singleton have these two steps in common:

Make the default constructor private, to prevent other objects from using the new operator with the Singleton class.
Create a static creation method that acts as a constructor. Under the hood, this method calls the private constructor to create an object and saves it in a static field. All following calls to this method return the cached object.

Real world problem

Government: A country can have only one official government. Regardless of the personal identities of the individuals who form governments, the title, “The Government of X”, is a global point of access that identifies the group of people in charge.
Database Connection: A shared connection object used by the entire application.
Logger: A logging utility that writes to a single file should arguably be a singleton to avoid file locking issues.

Pros and Cons

Pros	Cons
- Controlled Access: You can be sure that a class has only a single instance. - Global Access: You gain a global access point to that instance. - Lazy Initialization: The singleton object is initialized only when it’s requested for the first time.	- Violates SRP: The pattern solves two problems at the time. - Hides Dependencies: The pattern can mask bad design, for instance, when the components of the program know too much about each other. - Testing: The pattern requires special treatment in a multithreaded environment so that multiple threads won’t create a singleton object several times. It difficult to unit test the client code of the Singleton because many test frameworks rely on inheritance when producing mock objects.

Pros

Cons

- Controlled Access: You can be sure that a class has only a single instance.
- Global Access: You gain a global access point to that instance.
- Lazy Initialization: The singleton object is initialized only when it’s requested for the first time.

- Violates SRP: The pattern solves two problems at the time.
- Hides Dependencies: The pattern can mask bad design, for instance, when the components of the program know too much about each other.
- Testing: The pattern requires special treatment in a multithreaded environment so that multiple threads won’t create a singleton object several times. It difficult to unit test the client code of the Singleton because many test frameworks rely on inheritance when producing mock objects.

Comparison

Facade: Facade class can often be transformed into a Singleton since a single facade object is sufficient in most cases.
Flyweight: Flyweight would resemble Singleton if you somehow managed to reduce all shared states of the objects to just one flyweight object. But there are crucial differences (Flyweights are immutable, Singleton is mutable).
State: State objects are often Singletons.