Definition: SOLID is an acronym representing five object-oriented software design principles. When applied correctly, these principles make code easier to understand, maintain and extend.
— Source: NERVICO, Software Development Consultancy
What is SOLID
SOLID was introduced by Robert C. Martin ("Uncle Bob") and has become one of the fundamental pillars of professional software development. They're not rigid rules, but guides that help make better design decisions.
Each letter represents a different principle. Together, they form a framework for writing code that doesn't break when it grows.
S - Single Responsibility Principle (SRP)
"A class should have only one reason to change."
Each module, class or function should do one thing well. If you have a class that manages users AND sends emails AND generates reports, you have three reasons to change it. Split it.
Signs of violation:
- The class has too many public methods
- It's hard to name the class without using "and" or "or"
- Changes in one area affect unrelated others
O - Open/Closed Principle (OCP)
"Entities should be open for extension, closed for modification."
You should be able to add new functionality without modifying existing code. This is achieved through abstractions, interfaces and composition.
Practical example:
Instead of a switch with cases for each payment type (card, PayPal, Bitcoin), define a PaymentMethod interface and create a class for each type. Adding a new payment method doesn't require touching existing code.
L - Liskov Substitution Principle (LSP)
"Objects of a derived class should be able to substitute those of the base class without altering the correct behaviour of the program."
If you have a Bird class with a fly() method, and you create Penguin that inherits from Bird... you have a problem. The penguin can't fly. The design is wrong.
The solution:
Rethink the hierarchy. Perhaps Bird shouldn't have fly(), or you need a separate Flyable interface.
I - Interface Segregation Principle (ISP)
"Clients should not be forced to depend on interfaces they don't use."
It's better to have many specific interfaces than one general interface that includes everything. If a class implements an interface, it should use ALL its methods.
Example:
A Worker interface with work(), eat() and sleep() forces a robot to implement eat() and sleep(). Better to separate into smaller interfaces.
D - Dependency Inversion Principle (DIP)
"Depend on abstractions, not concretions."
High-level modules should not depend on low-level modules. Both should depend on abstractions. This allows changing implementations without touching the code that uses them.
In practice:
Instead of your UserService directly creating an instance of MySQLDatabase, it should receive a Database interface. This way you can switch to PostgreSQL or an in-memory database for tests.
Why SOLID Matters
- Maintainable code: Localised changes, no unexpected side effects.
- Testable: Isolated components that can be unit tested.
- Extensible: Add functionality without breaking existing code.
- Understandable: Each piece has a clear purpose.
- Reusable: Well-designed components can be used in other contexts.
When NOT to Apply SOLID (carefully)
SOLID can lead to over-engineering if applied dogmatically. A 50-line script doesn't need five levels of abstraction.
Use SOLID when code will grow, when a team works on it, when you need tests, when the project has a long life. Don't use it to complicate simple code.