The SOLID principles are five design guidelines for creating more maintainable and extensible classes in object-oriented programming.
In the previous post, we talked about cohesion and coupling. We concluded that our goal as developers is to achieve high cohesion and low coupling.
That sounds great in theory. But how do we achieve this in practice? What rules should you follow when writing a class to ensure you’re not creating a monster?
That’s where we use the SOLID principles. If object-oriented programming is the tool, SOLID helps us use it without hurting ourselves with it.
If you work on applications that will grow and be maintained over time, understanding SOLID will save you many headaches.
What is SOLID?
SOLID is a mnemonic acronym that groups five basic principles of object-oriented software design.
These principles were compiled by Robert C. Martin (the famous “Uncle Bob”) in the early 2000s, although the acronym itself was coined later by Michael Feathers.
The premise is simple: if you apply these principles wisely, your software will be easier to understand, maintain, and extend.
SOLID are not immutable “laws” like gravity. They are recommendations and principles that guide us towards better design. Sometimes there are reasons to break them, but you need to know very well why you’re doing it.
The SOLID principles
Let’s do a quick summary of each one. Don’t worry if some sound abstract now, because we’ll dedicate a full article to each principle with code examples.
| Letter | Principle | English Name | Quick Summary |
|---|---|---|---|
| S | Single Responsibility | Single Responsibility Principle (SRP) | A class should have only one reason to change. |
| O | Open/Closed | Open/Closed Principle (OCP) | Software should be open for extension, but closed for modification. |
| L | Liskov Substitution | Liskov Substitution Principle (LSP) | If a class B inherits from A, we should be able to use B in place of A without breaking anything. |
| I | Interface Segregation | Interface Segregation Principle (ISP) | It’s better to have many small, specific interfaces than one giant, general interface. |
| D | Dependency Inversion | Dependency Inversion Principle (DIP) | Depend on abstractions, not on concrete implementations. |
Why do we need SOLID?
To understand the solution, we first need to understand the problem. Robert C. Martin defines the symptoms of “bad design”. They probably sound familiar from a project you’ve suffered through:
- Rigidity: The system is hard to change because every change affects too many parts.
- Fragility: When you change something, the system breaks in places that apparently had no relation.
- Immobility: It’s hard to reuse parts of the code in other projects because it has too many dependencies (the problem of “I wanted the banana but I got the gorilla and the whole jungle).
- Viscosity: It’s easier to do things the wrong way (hacks) than to do them right while respecting the design.
The SOLID principles directly attack these symptoms.
Direct Benefits
By applying SOLID, we gain:
- Maintainability: The code is cleaner and easier to read. We know where to look when something fails.
- Scalability: We can add new features without having to rewrite half of the existing code (thanks to the OCP principle, for example).
- Testability: This is possibly the greatest immediate benefit. Decoupled code is much easier to test with unit tests.
Is SOLID the solution to everything?
SOLID is not the solution to everything. Applying it requires more effort upfront: we’ll write more classes, more interfaces, and more files. For a quick 50-line script, applying SOLID is over-engineering.
The art of software design lies in knowing when to apply these principles. Don’t try to apply SOLID to everything from day one. Refactor towards SOLID as the system grows and shows “pain”.
However, in an application intended to last over time and be maintained by a team, SOLID is a very useful reference.
