Hello dear readers. Today we are going to talk about SOLID, the first five principles of the object oriented design.
S.O.L.I.D is an acronym for the first five object-oriented design principle. When these principles are combined together, it makes it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid easily refactor code and are also a part of the agile or adaptive software development. SOLID stands for:
S – Single responsibility principle
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle
Single Responsibility Principle states that a class should only have one job, only one reason to change. The reason why we should use SRP is because it makes your software easier to implement and prevents unexpected side-effects of future changes. Another benefit of this principle is that classes and software components that have only one responsibility are much easier to understand, explain and implement than the ones that provide solution for everything.
Open/Closed Principle states that objects or entities should be open for extension but closed for modifications. Using this principle prevents situations in which a change to one of your classes also requires you to adapt all depending classes.
Liskov substitution principle states that every subclass/derived class should be substitute for their base/parent class. To achieve that, your subclasses need to follow the following rules: 1. Don’t implement any stricter validation rules on input parameters than implemented by the parent class. 2. Apply at the least the same rules to all output parameters as applied by the parent class.
Interface segregation principle states that a client should not be forces to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. By following this principle, you will be able to prevent bloated interfaces that define methods for multiple responsibilities. You should avoid classes and interfaces with multiple responsibilities because they change often and make your software hard to maintain.
Dependency Inversion principle states that entities must depend on abstractions not on concretions. High-lever and low-lever modules also depend on the abstraction. This design principle does not just change the direction of the dependency, it also splits the dependency between the two levels by introducing an abstraction between them.