What and Why??
SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin. In simple words, design principles help us to create more maintainable, understandable, and flexible software.
The goal of the SOLID principles is to reduce dependencies so that we can change one area of software without impacting others. Additionally, they’re intended to make designs easier to understand, maintain, and extend. Ultimately, using these design principles makes it easier for software engineers to avoid issues and to build adaptive, effective, and agile software.
While the principles come with many benefits, following the principles generally leads to writing longer and more complex code. This means that it can extend the design process and make development a little more difficult. However, this extra time and effort are well worth it because it makes software so much easier to maintain, test, and extend.
SOLID stands for:
- S – Single Responsibility Principle
- O – Open-Closed Principle
- L – Liskov Substitution Principle
- I – Interface Segregation
- D – Dependency Inversion
Single Responsibility Principle
This principle states that :
A class should have one and only one reason to change, meaning that a class should have only one job.
This means when we design our classes, we need to ensure that our class is responsible only for 1 task or functionality and when there is a change in that task/functionality, only then, that class should change.
Benefits of Single Responsibility Principle
- When an application has multiple classes, each of them following this principle, then the applicable becomes more maintainable, easier to understand.
- The code quality of the application is better, thereby having fewer defects.
- Testing and writing test cases is much simpler.
Open-Closed Principle
This principle states that :
Objects or entities should be open for extension but closed for modification.
This means that a class should be extendable without modifying the class itself.
The principle states that software entities like class, modules, functions, etc.; should be able to extend a class behavior without modifying it. This principle separates the existing code from modified mode to provide better stability, maintainability and minimizes the changes in the code.hanges as in your code.
Liskov Substitution Principle
Liskov Substitution Principle states:
Derived or child classes must be substitutable for their base or parent classes
This principle ensures that any class that is the child of a parent class should be usable in place of its parent without any unexpected behavior.
This principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes.
Interface Segregation Principle
Interface segregation principle states:
Do not force any client to implement an interface which is irrelevant to them
Here your main goal is to focus on avoiding fat interface and give preference to many small client-specific interfaces. You should prefer many client interfaces rather than one general interface and each interface should have a specific responsibility.
Dependency Inversion Principle
The dependency inversion principle states:
Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.
This principle allows for decoupling.
This states that if a high module or class will be dependent more on low-level modules or class then your code would have tight coupling and if you will try to make a change in one class it can break another class which is risky at the production level.