S.O.L.I.D
- SOLID Principles is a coding standard that all developers should have a clear concept for developing software in a proper way to avoid a bad design. this concept was created by Robert C Martin and is used across the object oriented design spectrum. When the programming developer builds a software there are some points make bad design. They are , the code can become flexible , small changes in the software can result in bugs. For these points we need to use the SOLID principles. 😇
- It takes some time to Understand , if you write code this principle we will improve many good things and improve the code quality.
Single Responsible Principle
- A class should have one and only one reason to change, meaning that a class should have only one job. This is not only about a class it what we consider as unit. Well lets take the class which does the following
- Open a Database Connection
- Fetch Data from Database.
- Write the data in an external file.
The issue with this class is that it handles alot of operations. Suppose any of the following changes will happens in future.
- New Database
- Adopt ORM to manage queries on database.
- Change in the output structure.
So in all the cases the above class would be changed. Which might affect the implementation of the other two operations as well. so ideally according to "Single Responsible Principle" there shpuld be three classes each having is good.
- It takes some time to Understand , if you write code this principle we will improve many good things and improve the code quality.
Single Responsible Principle
- A class should have one and only one reason to change, meaning that a class should have only one job. This is not only about a class it what we consider as unit. Well lets take the class which does the following
- Open a Database Connection
- Fetch Data from Database.
- Write the data in an external file.
The issue with this class is that it handles alot of operations. Suppose any of the following changes will happens in future.
- New Database
- Adopt ORM to manage queries on database.
- Change in the output structure.
So in all the cases the above class would be changed. Which might affect the implementation of the other two operations as well. so ideally according to "Single Responsible Principle" there shpuld be three classes each having is good.
Open and Close Principle
- Objects or entities should be open for extension, but closed for modification. The simple means that a class should be extendable without modifying the class itself.
👉open for extension
This ensures that the class behavior can be extended. As requirements change, we should be able to make a class behave in new and different ways, to meet the needs of the new requirements.
👉Closed for Modification
The Source code of such a class is set in stone, no one allowed to make changes to code.
- For Example, Just assume We have X class which is developed by Xman. If the developer Yman wants some modification on that then developer Yman should do that easily by extending A class. BUT NOT MODIFYING CLASS A.
Liskov substitution Principal
- Every subclass or derived class should be able to substitute their parent or base class.
Example:-
Lets consider we have a class called Animal.
In our code we were using Animal object we must be able to replace it with Dog/ Cat without exploding our code. What do we means here is the child class should not implemented code and it is replaced by the parent class then the application will stop running.
If the above class is replaced by Animal then our Application will crash.
Interface Segregation Principal
- Clients should not be forced to implements methods they do not use.
Example:-
👉 Lets says we have an interface called Animal, which would have eat, sleep, and walk methods. This would mean that we have a monolithic interface called Animal, because some animals can fly. Breaking this monolithic interface into smaller interfaces based on role, we would get canEat,canSleep and CanWalk interfaces. species would be a combination of roles , instead of being characterized as an animal, which would not necessarily be the best description.We favor composition by separating by roles and Decoupling by not coupling derivative classes with unneeded responsibilities inside a monolith.
👉 Lets says we have an interface called Animal, which would have eat, sleep, and walk methods. This would mean that we have a monolithic interface called Animal, because some animals can fly. Breaking this monolithic interface into smaller interfaces based on role, we would get canEat,canSleep and CanWalk interfaces. species would be a combination of roles , instead of being characterized as an animal, which would not necessarily be the best description.We favor composition by separating by roles and Decoupling by not coupling derivative classes with unneeded responsibilities inside a monolith.
Dependency inversion Principal
- Higher level modules should not depend on lower level modules, but they should depend on abstractions.
- Think three tier architecture. Business Logic layer Depends on the Database access layer.
- It means that we should be having object of f interface which helps us to communicate with the concrete classes. What do we gain from this is, we hide the actual implementation of class A from Class B. So if class A changes, class B doesn't need to care or know about the changes.
