SOLID at a glance

The SOLID principles are a set of five design guidelines for object-oriented programming, intended to make software designs more understandable, flexible and maintainable. Following them helps developers avoid common design pitfalls such as high coupling and low cohesion. The result is systems that are easier to extend, and less prone to bugs when changes are made.

These principles are not isolated rules. Together they form a holistic framework for good object-oriented design, and understanding how they interact is crucial for making sound architectural decisions:

• The Open/Closed PrincipleOpen/Closed PrincipleOpen for extension, closed for modification.Opens in a new tab often relies on abstractions (interfaces or abstract classes), which directly relates to the Dependency Inversion PrincipleDependency Inversion PrincipleHigh-level code should depend on abstractions, not on concrete low-level classes.Opens in a new tab.
• The Liskov Substitution PrincipleLiskov Substitution PrincipleA subtype must be usable anywhere its base type is.Opens in a new tab ensures those abstractions are implemented correctly.
• The Interface Segregation PrincipleInterface Segregation PrincipleMany small interfaces beat one big one.Opens in a new tab helps define granular, focused abstractions.
• The Single Responsibility PrincipleSingle Responsibility PrincipleA class should have only one reason to change.Opens in a new tab contributes by creating components that are easier to manage in terms of dependencies and extensions.

Quick reference

Principle	Core idea	Key benefit in C# and .NET	Common C# implementation technique
Single Responsibility	A class should have only one reason to change.	Improved cohesion, easier maintenance and testing, reduced impact of changes.	Smaller, focused classes. Delegation of responsibilities.
Open/Closed	Software entities should be open for extension, but closed for modification.	Add new features without altering existing, tested code. Increased stability.	Abstract classes, interfaces, polymorphism, the strategy pattern.
Liskov Substitution	Derived classes must be substitutable for their base classes.	Ensures correct behavior in polymorphic scenarios. Maintains abstraction integrity.	Careful design of inheritance hierarchies. Honoring base class contracts.
Interface Segregation	Clients should not be forced to depend on interfaces they do not use.	More cohesive interfaces, reduced coupling, better maintainability.	Smaller, role-specific interfaces.
Dependency Inversion	High-level modules depend on abstractions, not concretions. Details depend on abstractions.	Loose coupling, increased flexibility and testability. Easier to swap implementations.	Interfaces, dependency injection (DI).