The hidden cost of a single shared instance
A Singleton is usually created by making a class responsible for keeping its sole instance and providing a familiar way for other code to retrieve it. That can be useful when an application truly needs one coordinator or one connection manager. But when the instance also holds changing data, it becomes a shared place where unrelated parts of the program can read and write state.
The coupling is easy to miss because callers do not receive the instance through their normal inputs. A method may appear to depend only on its arguments, while quietly consulting a Singleton for settings, a cache, or the current user. Its behavior now depends on something outside its visible interface.
Why this makes change and testing harder
Suppose one feature updates a shared preference and another reads it later. The second feature’s result depends on what the first one did—and on whether some other code changed the preference in between. To understand a bug, a developer may have to trace every place that can reach the Singleton, not just the method that failed.
Tests face the same problem. A test can leave data behind for the next test, making results depend on execution order. Resetting the Singleton between tests can help, but it adds another special mechanism and may still miss state held elsewhere.
One instance is not always the problem
The pattern itself is not automatically harmful. A single, immutable service or a deliberately managed resource may be straightforward to share. The risk rises when access is available everywhere and the instance carries mutable application state. Passing a dependency explicitly instead makes that relationship visible: readers can see what a component needs, and tests can supply a controlled alternative.
The practical warning is simple: if changing one “convenient” shared object can alter distant behavior, the code has acquired the reach of global state—even if the object is neatly wrapped in a class.
