What is the Singleton pattern?

Question

Accepted Answer

The **Singleton** pattern ensures a class has only **one instance** and provides a global point of access to it. It's used when exactly one object should coordinate something (a configuration, a connection pool, a logger), though it's also somewhat controversial.

## What Singleton does

```text
SINGLETON → guarantee a class has only ONE instance, with global access to it:
  → the class controls its own instantiation (private constructor)
  → returns the SAME instance every time it's requested
→ for: things there should only be ONE of, accessed from many places
```

## Example

```js
class Config {
  static #instance;
  static getInstance() {
    if (!Config.#instance) {
      Config.#instance = new Config();   // create once
    }
    return Config.#instance;             // always return the same instance
  }
}
// Config.getInstance() always returns the same object
```

## Common uses and the controversy

```text
USES → configuration objects, loggers, connection pools, caches (one shared instance)
⚠️ CONTROVERSIAL → Singletons are often criticized:
  → GLOBAL STATE in disguise → hidden dependencies, hard to TEST (can't easily mock/replace),
    tight coupling, issues with concurrency
  → often better: DEPENDENCY INJECTION (pass the single instance in) → same "one instance"
    benefit but testable and explicit
→ use sparingly; consider DI as an alternative; valid for genuinely-single resources
```

## Why it matters

Understanding the Singleton pattern is valuable because it's one of the **most well-known design patterns** (frequently encountered and discussed), and understanding it — including its controversies — reflects good design judgment.

Singleton ensures a class has only one instance with global access, used when there genuinely should be only one of something (configuration, logger, connection pool, cache) accessed from many places.

Understanding what it does (a class controlling its own instantiation to return the same instance every time) is the basic knowledge.

However, understanding the **controversy** is equally important and reflects mature judgment: Singletons are widely criticized because they're essentially **global state in disguise**, creating **hidden dependencies** (code using a Singleton has an undeclared dependency), making code **hard to test** (you can't easily mock or replace the single instance), causing tight coupling, and posing concurrency issues.

Understanding that **dependency injection is often a better alternative** (passing the single instance in, providing the same "one instance" benefit but in a testable, explicit way) reflects the design judgment to prefer DI over Singletons in many cases.

This balanced understanding — knowing the pattern but also its problems and better alternatives — is what distinguishes thoughtful use from cargo-culting.

Since Singleton is one of the most well-known and frequently-discussed patterns, and since understanding it along with its significant controversies (global state, testability problems) and the dependency-injection alternative reflects good design judgment, understanding the Singleton pattern is valuable, commonly-relevant knowledge — a famous pattern worth understanding, where appreciating its drawbacks (global state, hard to test) and the preference for dependency injection in many cases reflects the mature design judgment that distinguishes thoughtful developers, and a frequently-encountered and discussed topic in software design.