The SOLID principles of Object-Oriented Design
In Object-oriented programming, SOLID is an acronym for the five basic principles to be kept in mind while designing the software to make it more flexible, understandable, and maintainable.
The theory of Solid principles was given by Robert C Martin aka Uncle Bob and the SOLID acronym was later introduced by Micheal Feathers.
The SOLID design principles are :
- Single Responsibility Principle
- Open/Closed Principle
- Liskov’s Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
The “S” in SOLID stands for the Single Responsibility Principle.
Each software module should have one and only one reason to change.
When you write a software module, you want to make sure that each module is having only one functionality. When a new functionality comes up, it is added in a separate module. You want to isolate your modules from the complexities of the organization as a whole.
When do we break the SRP principle?
When you create a class with more than one functionality, then this principle is broken. It makes the code lengthy, complex and tightly coupled.
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
If you think about this you’ll realize that this is just another way to define cohesion and coupling. We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.
Open/Closed Principle
The “O” in SOLID stands for the Open/Closed Principle.
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
What is open and closed here?
- A module will be said to be open if it is still available for extension. It should be possible to extend a class and add new features to the derived class.
- A module will be said to be closed if it is available for use but cannot be modified by other modules.
When do we break the Open-Closed Principle?
When we need to add new features or new behaviors to an existing class, adding it in the class itself breaks this principle.
Liskov’s Substitution Principle
The “L” in SOLID stands for the Liskov Substitution Principle.
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Derived or child classes must be substitutable for their base or parent classes.
When do we break the LSP principle?
When child class object cannot be used in place of parent class object, this principle is broken.
Interface Segregation Principle
The “I” in SOLID stands for the Interface Segregation Principle.
Many client-specific interfaces are better than one general-purpose interface.
We should not force a class to implement an interface that is irrelevant to it. A class should implement only those interfaces whose properties/functionalities it wants to implement.
When do we break the ISP principle?
Adding an irrelevant interface property to a class breaks this principle. For example, when a vegetarian person goes to a restaurant and asks for the menu, the menu provided to him contains vegetarian as well as non-vegetarian dishes. Non-vegetarian dishes are irrelevant to him and this is where the ISP principle is broken. According to this principle, only vegetarian dishes menu card should be given to him.
Dependency Inversion Principle
The “D” in SOLID stands for the Dependency Inversion Principle.
One should depend upon abstractions and not concretions.
- According to this principle, high-level code should not depend on the low-level code. Both high-level and low-level code should depend upon abstraction.
- Also, abstraction should not depend upon the details but details should depend on abstraction.
It helps in decoupling the dependencies between the classes so that modification made to a class does not require modifications to be made to another class.
When do we break the DIP principle?
When a concrete class depends on another class rather than solely depending upon abstractions, this principle is broken. It leads to tight coupling between the classes.
