I have given a simpler explanation on the SOLID design principle without having any reference to a programming language.
Pre-Requsities
Understanding of :
- Coupling
- Cohesion
- Inheritance
- Polymorphism
- Abstraction
SOLID is an acronym for :
S – Single Responsibility principle
O – Open/Closed principle (Open for extension; Closed for Modification)
L – Liskov Substitution principle
I – Interface Segregation principle
D – Dependency Inversion principle
S – Single Responsibility principle
What?
A class (or) component (or) a module (or) a micro service should have
| ONE and ONLY ONE REASON to change | and the reasons for change should be mapped to | ONE and ONLY ONE RESPONSIBILITY |
Following reasons does not fall under a responsibility to change.
- Bug fix
- Code refactoring
Why?
Reason for change should originate based on the defined responsibility of the class/component/module. When there are more than one reason it becomes so fragile and bloated with more responsibilities.
How?
Concept called as “Separation of Concerns” helps to achieve this principle.
Any component that has a tendency to change for same reasons then group them together. Any component that has a tendency to change for different reasons then separate them.
O – Open/Closed principle
What?
Open / Closed principle states that any classes/modules should be Open for extension, but closed for modification.
It means, without changing its behaviour the class or module should be available for extension.
Why?
Consider, the modern IDE’s (Eclipse, Atom, Sublime, Visual Studio code etc.,). You like a feature in Atom and it’s not available in Sublime (or) vice versa. If you have to introduce the “liking” feature in your IDE, you are installing via a plugin which provides the necessary feature. It’s not that you are modifying the original IDE code.
Inspite of this, if you are modifying the original behaviour it tends to start creating problems.
How?
Best way is to follow a plugin approach.
L – Liskov Substitution Principle
What?
Liskov Substitution principle talks about how subtypes must be substitutable for their base types.
Why?
It extends Open/Closed principle by focusing on behaviour of superclass and subtypes. By following LSP, the advantage we get is code-reusability, low coupling. When wrongly implemented, then in the object oriented programming we are likely violating “IS-A” relationship.
How?
Let Subtypes perform pre and post condition changes similar to super types
I – Interface Segregation Principle
What?
Clients should NOT be forced to use interfaces that they don’t use.
Why?
Helps to avoid:
- Fat Interface
- Forced method implementation
How?
Use composition, combine SRP and segregate interfaces
D – Dependancy Inversion Principle
What?
Abstractions should not depend on details; Details should depend on abstractions
Why?
Dependancies represent risk. If the dependancies are not abstracted then the risk is higher.
How?
Dependancy Injection (DI) – Wiring.
Inversion of Control (IOC) – Direction.
DIP – Shape.
References / Inspirations
https://martinfowler.com/articles/dipInTheWild.html
http://www.principles-wiki.net/principles:dependency_inversion_principle