SOLID design principles introduced by Uncle Bob
Let’s simplify this for the sake of learning…
Problems without solid principles:-
- Re-reading code multiple times to get familiar with the codebase to make new changes as per requirement.
- Hard to understand what a method does.
- Spending a lot of time to fix a minor bug.
- Eventually, you are going to spend more time to read than write.
- Solid design principles encourage us to create more maintainable, understandable, and flexible software.
S -> Single Responsibility Principle:-
A class should have only one responsibility or we can say a class should have only one reason to change.
By using this principle we have less coupled, well organised and easy testable class.
let’s look at an example:-
As we know that ViewModel uses for handling the business logic and here we are handling local database transaction so this viewModel has two responsibilities which are violating the Single Responsibility behaviour,
let see how we can fix this.
So now we have moved all database transaction in repo class and now viewModel has one responsibility which is handling the user data.
O -> Open-Closed Principle:-
This principle says that classes should be open for extension, but closed for modification.
By using this principle we can restrict ourselves to creating bugs by modifying existing code so instead of this we will add new code.
let’s look at an example:-
Suppose we have launched a version of our application previously and now we want to add some more functionalities to above class like no. of stocks is available for our next version so instead of adding the code in existing class which might create some bug in our application, we create a new class by extending this above class.
by using this we can make sure that we will not be having any bug in existing code.
L -> Liskov Substitution Principle:-
Child classes should never break the parent class’ type definitions.
This is a most complex principle as many people say but dont worry I will make this simple for you.
This principle says that a child class should override the methods from a parent class that does not break the functionality of the parent class.
let’s look at an example:-
Here we can see that we are using a normal engine that will turn on manually but what if we want to add electric engine after some time.
let’s see by doing.
So above we are violating this principle because we are changing the functionality of parent class, instead of doing this we can do as follow:-
I -> The Interface Segregation Principle:-
Larger interfaces should be split into smaller ones.
By using this principle we can make sure that child classes only going to use the methods that are useful to them.
let’s look at an example:-
As you can see we are violating of Interface Segregation Principle, so we can divide our fat interface into small interfaces.
Now we can use these interfaces as per our requirements.
D -> The Dependency Inversion Principle:-
The last principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
The main idea of the principle is not to have direct dependencies between the modules and classes. Try to make them dependent on the abstractions (e.g. interfaces) instead.
let’s look at an example:-
So as the device increase we have to change above copy method each time, so instead of this let's simplify this.
so now our code independent of device and we can add more devices without modifying our existing code.
IMP* Notes
- SOLID design principles are principles, not rules.
- Always use common sense when applying SOLID.
- Avoid over-fragmenting your code for the sake of SOLID.
- Don’t try to achieve SOLID, use SOLID to achieve maintainability.
Final Thoughts
- The purpose of SOLID is to make your code more maintainable, understandable, flexible, easy to extend and reason about.
- it requires spending more time writing code, so you can spend less reading it later.
- SOLID design principles are principles, not rules.
- Always know your trade-offs and use common-sense.
- SOLID IS YOUR TOOL, NOT YOUR GOAL
Original Article: https://www.readerlook.com/solid-design-principles-introduced-by-uncle-bob/
