S.O.L.I.D Design Principles: Design Your Software Better
Introduction for S.O.L.I.D
SOLID principles are one of the best software designing principle which will be a guide for designing software which are easy to maintain , understand and extend too.
This principle helps developers to organize code in better way that will make every one to work on the existing project without hesitation.
S.O.L.I.D design principle will guide you to:
- Write code which is easy to maintain.
- Write code which is easy to read and understand.
- Easier to extend with new functionality without breaking the existing ones.
- Reduce tight coupling.
What does S.O.L.I.D stands for?
Single Responsibility Principle
This principle states that “Every class or module should have only a single responsibility”.
Explaining in simple words,
Normally when we design a software its requirements changes over time. They will change the responsibility of at least one class. If we have multiple responsibilities in one class we need to change the class as soon as on of its responsibility changes.
Then if another class depends on this class, that another class also need to be changed. This will make our program more complicated and consume more time.
In order to prevent this we need to use “Single Responsibility Principle”. If one class is responsible to adding user details to database that it shouldn’t care about updating the user data. Updating user need to be consider as another responsibility and should be handle separately.
Single Responsibility Principal is mildly focusing on the Abstraction concept of Object Oriented Programming.
Open/Close Principle
This principle states that “Software entities(class, module, function) should be open for extension but close for modification”.
Explaining in simple words,
“Open for extension” means that we should design the classes which we can add new functionalities can be integrate.
“Close for modification” means that once you have developed a class it shouldn’t be modified.
So the whole principle is saying that the design and writing of the code should be done in a way that coding new functionality should be able to integrate without changing the existing class.
“A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients.”
Open/Close principle strongly focusing on Abstraction concept of Object Oriented Programming.
Liskov Substitution Principle
This principle states “we should be able to substitute a parent class with any of its child classes, without breaking the system”.
Example: If S is a subtype of T, then objects of type T may be replaced with objects of type S.
This principle requires the objects of the sub class (child class) to behave in the same way as the objects of its super class (parent class) because of the inheritance concept in Object Oriented Programming.
Even the dog and the dog’s shadow are look like same they won’t satisfy this principle.
Interface Segregation Principle
This principle states “Clients should not be forced to depend upon interfaces that they do not use”.
This is basically says that don’t depend on things you don’t need. Easier to violate the concept, especially when the software grows eventually when the new requirements arise we need to add more features.
Instead of creating one larger interface we can break down it to smaller interfaces to ensure that implementing classes only need to be concerned about the methods with each one serving one submodule.
Dependency Inversion Principle
This principle states “High-level modules should not depend on lower-level modules. Both should depend on abstraction”.
By combining the dependency injection technique with the concept of binding an interface to a concrete implementation, we can make sure we never depend on concrete classes.
Let’s explain like this. We are using electricity to plug in laptop, phone, fridge etc. They all have a unified interface to get electricity: the socket. The beauty of it is that we don’t need to care about the way the electricity is provided. You simply rely on the fact that you can use it when needed.
Conclusion
It is always better to use S.O.L.I.D principles while designing software. It is like a guide for designing better software.
References
