The Singleton Pattern

archetype Social Roles → Object-Oriented Design

What It Brings

The name imports the concept of singular, unrepeatable identity into a domain where copying is the default operation. In mathematics, a singleton is a set with exactly one element. In social life, certain roles are structurally unique — there is one Pope, one sitting monarch, one lead conductor on the podium. The pattern maps this exclusivity onto object instantiation: there shall be exactly one instance of this class, and everyone shares it.

Key structural parallels:

Uniqueness as a constraint, not an accident — a singleton is not merely the only instance that happens to exist; it is the only instance that can exist. The metaphor captures this distinction well. A monarch is not just the person who currently rules; the role structurally forbids a second occupant. The pattern enforces this at the language level with private constructors and static access.
Global accessibility follows from uniqueness — if there is only one of something, everyone must share it. The Pope does not belong to a particular parish. A singleton instance does not belong to a particular caller. The metaphor naturally implies a global access point, which is exactly what getInstance() provides.
The role outlives any particular occupant — in social systems, singleton roles persist across generations. The office of the presidency endures; the president changes. In software, the singleton instance typically lives for the entire application lifecycle, outliving the scopes that use it. The metaphor correctly suggests permanence.

Where It Breaks

Social singletons exist for legitimacy; software singletons exist for convenience — a kingdom has one monarch to prevent civil war. A database connection pool has one manager because someone was too lazy to pass it as a parameter. The metaphor imports gravitas that the usage rarely deserves. Most singletons are not structurally necessary; they are architectural shortcuts dressed up as constraints.
Social singletons are visible; software singletons hide — a monarch is the most public figure in the realm. A software singleton is often invisible to callers who receive it through static methods, making dependencies opaque. The metaphor suggests centrality and prominence, but the actual pattern produces hidden coupling — the opposite of what “there can be only one” implies about visibility.
Uniqueness in social systems is enforced by consensus; in software it is enforced by mechanism — a usurper can challenge a monarch; a private constructor cannot be challenged (without reflection). The metaphor suggests that singleton status might be contested or negotiated. In practice, it is a hard mechanical lock. This makes the social metaphor too soft for what is actually happening.
The metaphor does not warn about testing — the deepest practical problem with singletons is that they resist substitution. You cannot easily swap in a mock monarch for testing purposes. Social roles do allow stand-ins (regents, acting presidents), but the singleton pattern as typically implemented does not. The metaphor’s source domain actually has more flexibility than the target, which is unusual and misleading.
“Singleton” sounds elegant; the reality is often an anti-pattern — the mathematical precision of the name lends respectability to what the software community increasingly considers a code smell. Global mutable state, hidden dependencies, and test-hostile design are not problems that “singleton” prepares you for. The name makes the pattern sound inevitable and clean when it is frequently neither.

Expressions

“There can be only one” — the Highlander tagline, widely used in developer discourse to explain singleton intent
“Global instance” — the operational reality behind the elegant name, collapsing “singleton” back to “global variable”
“Singleton abuse” — the recognition that the pattern’s clean metaphor enables overuse
“God object” — what a singleton becomes when it accumulates responsibilities, a theological escalation of the uniqueness metaphor
“Double-checked locking” — the thread-safety ritual around singleton creation, a concern the metaphor completely fails to surface
“Dependency injection killed the singleton” — the modern consensus that explicit wiring is better than implicit global access

Origin Story

The Singleton pattern was codified in Design Patterns (1994) by the Gang of Four, though the practice of restricting instantiation predates the book. The mathematical term “singleton” (a set with one element) was borrowed to give the concept precision and legitimacy.

The pattern became one of the most widely used — and most widely criticized — of the original 23. Its simplicity made it the first pattern many developers learned, and its problems made it the first pattern many developers learned to avoid. The arc from “elegant solution” to “probable anti-pattern” tracks the broader maturation of the OOP community’s relationship with global state.

The “Highlander” association (“There can be only one”) entered developer culture early and stuck, giving the pattern a memorable slogan that both explains it and slightly oversells it.

References

Gamma, E. et al. Design Patterns: Elements of Reusable Object- Oriented Software (1994)
Fowler, M. “Inversion of Control Containers and the Dependency Injection Pattern,” martinfowler.com (2004) — the beginning of the end for casual singleton usage
Hevery, M. “Singletons are Pathological Liars,” Google Testing Blog (2008) — the testing community’s case against singletons