Which SOLID principle does the Singleton pattern technically violate?

Which SOLID principle does the Singleton pattern technically violate?

• A. Open/Closed — it cannot be extended without modification
• B. Liskov Substitution — it changes behavior of subclasses
• C. SRP — it handles both data storage and instance control
• D. Dependency Inversion — high-level modules depend on abstractions

Answer: (C)

Single Responsibility Principle states that a class should have only one reason to change. A singleton typically blends two concerns in one class: its core business behavior and the mechanics of ensuring there is only one instance (the instantiation policy, global access point, lazy initialization, thread safety, etc.). Because of this, any change to how the instance is created or accessed would require touching the same class that contains the domain logic, giving it more than one responsibility to manage. That dual duty means the class has multiple reasons to change, which violates SRP. In practice, this is why singletons can make code harder to maintain and test: the global, shared state couples clients to a concrete implementation and to the singleton itself. While other SOLID principles can be affected in various ways (for example, depending on concrete types can hinder Dependency Inversion, or trying to extend behavior can feel at odds with Open/Closed), the most direct mismatch is with SRP because the singleton enforces two separate responsibilities inside one class.

Single Responsibility Principle states that a class should have only one reason to change. A singleton typically blends two concerns in one class: its core business behavior and the mechanics of ensuring there is only one instance (the instantiation policy, global access point, lazy initialization, thread safety, etc.). Because of this, any change to how the instance is created or accessed would require touching the same class that contains the domain logic, giving it more than one responsibility to manage. That dual duty means the class has multiple reasons to change, which violates SRP.

In practice, this is why singletons can make code harder to maintain and test: the global, shared state couples clients to a concrete implementation and to the singleton itself. While other SOLID principles can be affected in various ways (for example, depending on concrete types can hinder Dependency Inversion, or trying to extend behavior can feel at odds with Open/Closed), the most direct mismatch is with SRP because the singleton enforces two separate responsibilities inside one class.