Singleton Anti Pattern

In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one “single” instance. This is useful when exactly one object is needed to coordinate actions across the system. The term comes from the mathematical concept of a singleton.

Critics consider the singleton to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application.

The singleton design pattern solves problems like:

• How can it be ensured that a class has only one instance?
• How can the sole instance of a class be accessed easily?
• How can a class control its instantiation?
• How can the number of instances of a class be restricted?
• How can a global variable be accessed?

The singleton design pattern describes how to solve such problems:

• Hide the constructor of the class.
• Define a public static operation (getInstance()) that returns the sole instance of the class.

The key idea in this pattern is to make the class itself responsible for controlling its instantiation (that it is instantiated only once).

Common uses

• The abstract factory, factory method, builder, and prototype patterns can use singletons in their implementation.
• 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.

Anti-pattern considerations

The Singleton Pattern is generally considered an anti-pattern for the following reasons:

Singleton classes break object-oriented design principles

• It cannot be inherited from. To add new functionality, a new class cannot be descended to contain that functionality, breaking Separation of Concern.
• No control over creation. It is impossible to tell if a reference is of an existing instance or a new instance.
• Prevents dependency injection. As there is only a single instance of the class, a dependency cannot be injected into it. If done via a property, the dependency is changed for all references to that instance.

Singleton classes do not allow for test-driven development (TDD)

• As there is no control over creation, a "clean" instance of the object cannot be used for each test.
• Without dependency injection mock, objects cannot be used in tests.