Why is the Singleton pattern widely criticised, and how does injecting a single shared instance via dependency injection address those criticisms while still guaranteeing one instance?

## Terms first - **Global mutable state**: data reachable from anywhere that can be changed by anyone. It defeats local reasoning — the behaviour of a function depends on what other code did earlier. - **Hidden (implicit) dependency**: a collaborator a class uses without receiving it. Nothing in the class's public shape reveals it. - **Composition root**: the single place near the program's entry point where the object graph is wired. Everything else receives its collaborators. - **Dependency injection (DI)**: passing collaborators in (usually via the constructor) rather than letting the class find them. A **DI container** automates that wiring; its **singleton scope** means "create one instance and reuse it for every injection point". - **Service locator / ambient context**: a global registry that code queries for its collaborators. This is Singleton wearing a hat — it fixes substitutability but keeps the hidden-dependency problem. ## Criticism 1 — global mutable state Once a singleton holds mutable fields, any component can change what every other component observes. Effects: - **Non-local reasoning**: to understand a method, you must know the history of every writer. - **Concurrency**: shared mutable state accessed from many threads needs a coherent locking or immutability story; because access is easy and invisible, this is exactly where it is usually forgotten. - **Temporal coupling**: correctness depends on "configure it before anyone reads it", enforced by nothing. ## Criticism 2 — hidden dependencies ``` class Invoice { total() { return sum(lines) * TaxPolicy.getInstance().rate() } } ``` `Invoice`'s constructor claims it needs only lines. In truth it needs a tax policy, an initialised one, initialised *before* this call. Consequences: the module dependency graph is not derivable from signatures, architectural boundaries (layering rules, module allow-lists) are trivially bypassed because a static call is invisible to most structural checks, and a change to the singleton's contract ripples to callers you cannot enumerate. ## Criticism 3 — testability A static accessor is not a seam. Concretely: - You cannot hand `Invoice` a fake tax policy; you must mutate the real global or reach for bytecode-level static mocking, which is slow and brittle. - **State bleeds across tests** in the same process: test A configures the singleton, test B silently depends on that, and the suite passes only in one order. - **Parallel tests** in one process share the instance, so isolation is impossible without ugly serialization. - A `reset()` for tests is production code existing only for tests — and it is itself global mutable state, so it can be called at the wrong time. - Tests that *must* run integration-style because of one static call are slower and flakier than they need to be. ## Criticism 4 (often forgotten) — lifetime is compiled in Because the class decides it is unique, you cannot later say "one per tenant", "one per request", or "two, pointed at different regions" without editing every call site. Requirements change; the pattern makes that change maximally expensive. ## What DI actually changes — and what it doesn't ``` // composition root — one instance, created once policy = new TaxPolicy(config) invoice = new Invoice(lines, policy) ``` - **Uniqueness: preserved.** Only the root constructs it, so there is exactly one for the application's lifetime. - **Global access point: removed.** Access requires having been given the reference, which restores the dependency to the type signature. - **Testability: solved structurally.** `new Invoice(lines, fakePolicy)` needs no framework, no reset hook, no static mocking, and is parallel-safe because each test builds its own graph. - **Global mutable state: only partly addressed.** A single injected instance shared by everyone is still shared mutable state if it has mutable fields. DI makes it *visible* and *replaceable*, not automatically safe. The real fix is immutability or a well-defined thread-safe contract. That last point is the senior-level nuance interviewers listen for: DI cures the *hidden* and *unsubstitutable* parts, not the *shared mutable* part. ## Terminology trap: "singleton scope" ≠ Singleton pattern When a framework registers a service as a singleton it means *lifetime = one per container*. The class stays an ordinary type with a public constructor, implements an interface, and can be constructed freely in tests. The GoF pattern instead compiles the constraint into the class. Saying "we use singletons everywhere" is ambiguous — clarify which you mean. ## When the classic pattern is still defensible - **Bootstrap-level facilities** that exist before any container: a logging facade, a crash handler, process-wide metrics. Even here, prefer a thin static facade that *delegates* to an injectable implementation, so the static is an adapter rather than the logic. - **Genuinely exclusive resources** where a second instance is a correctness bug (a device handle, a process-wide lock). - **Stateless, immutable values** (a null object, a comparator) where sharing is a harmless optimisation. ## Migration seam The standard refactoring: extract an interface, make the singleton's methods instance methods, keep `getInstance()` as a thin delegating adapter, then push constructor injection outward call site by call site, and finally delete the accessor. You never need a big-bang rewrite — the static accessor can coexist with injection during the transition.