S.O.L.I.D Principles
What are solid principles?
Many design rules, patterns, or concepts exist in the area of object-oriented programming (OOP). The acronym SOLID stands for five of these concepts, which are frequently combined together. While each of these five principles expresses a distinct concept, they overlap to the point where embracing one implies or leads to the adoption of another.
- S- stands for Single Responsibility Principle (SRP)
- 0- stands for Open Closed Principle (OCP)
- L- stands for Liskov’s Substitution Principle LSP)
- I-stands for Interface Segregation Principle (ISP)
- D-stands for Dependency Inversion Principle (DIP)
The features of using S.O.L.I.D are :
- It becomes easier to design software that can be managed when all of the S.O.L.I.D principles are used together.
- It avoids code smells.
- Quickly refactor code.
- Can do adaptive or agile software development.
What are the advantages of using SOLID Design Principles?
- To make the code easier to maintain.
- The use of SOLID principles in the code will make the entire debugging process much
Single Responsibility Principle
“A class should have only one reason to change, which means it should only have one job.”
The important of this principle is:
It simplifies the implementation software and guards against unintended consequences of future revisions.
Open Closed Principle
“Objects or entities(class, modules, functions) should be open for extension, but closed for modification”
Inheritance and Polymorphism are commonly used to implement the open/closed principle.
How to find the open/closed principle?
Consider a class that calculates the area of a circle and a square and displays the result as a console value.
What if this class needs to figure out the area of a triangle? To keep classes extensible, use abstraction.
When there is a significant chance of change, rely on abstractions rather than concrete implementations.
Liskov substitution Principle
“Every subclass should be able to substitute their parent class”
When extending a class, it should be able to execute the same basic functions as the base class.
Unimplemented methods should not be present in a child class.
After overriding methods in the base class, the child class should not give them a different meaning.
Interface segregation principle
“Clients should not be forced to implement methods they do not use”
The goal of this principle is:
by reducing application interfaces into smaller ones, to lessen the negative effects of employing larger interfaces
Dependency inversion principle
“Higher level modules should not depend on lower-level modules, but they should depend on abstractions”
I hope you found this useful. I would like to hear from you so feel free to drop a comment or connect with me via LinkedIn.