SOLID Principles: Why and How?
In this article, we will be learning about SOLID principles. This is the biggest need of the time as we all write the code every day and it becomes a tedious task to make changes into them.
Why you need them:
An application should take care of frequent changes that are done during the development and maintainability phase.
For example, new functionality has to be added. those changes should be done with minimum code change in the existing code which is already tested.
To increase the modularity, extensibility, readability, testability, and scalability of your code.
When these principles are applied properly they make your code more extendable, logical, and easier to read.
Who should use them:
SOLID principles are for each developer from beginners to advanced levels.
So now I think I have given you enough points to convince you to use SOLID principles.
let’s start with the abbreviations.
S -> Single Responsibility Principle
O -> Open for extension and closed for modification Principle
L -> Liskov substitution Principle.
I -> Interface segregation Principle
D -> Dependency Inversion Principle ( I call it dependency injection too, about spring boot)
Single Responsibility Principle:
EACH ENTITY (CLASS/METHOD) WILL HANDLE A SINGLE RESPONSIBILITY.
A software entity (class/method) should have only one reason to change.
If a class or a method does more than one procedure, it is advisable to break those procedures into multiple classes/methods.
It can be easily done with the help of interfaces.
So if you have two reasons to change a class we should break that class into two separate classes.
Open-close Principle:
WE MUST KEEP AS MUCH EXISTING CODE UNCHANGED AS POSSIBLE.
Open closed principle states that the design and writing of the code should be done in a way that the new functionality should be added with the minimum changes in the existing code.
Software entities should be open for the extension but closed for the modification.
We have to design every new module -> if we add a new behavior, do not have to change the existing modules
Closely related to the single responsibility principle!
A class should not extend another class explicitly. We should have a common interface.
Why? Because we can change the classes at runtime due to the common interface!
For example, we want to show a progress dialog but it can due to some download or loading of some music, etc. We want to decide at runtime why we want to show the dialog.
Liskov Substitution Principle:
What is the motivation of the Liskov principle? We usually create class hierarchies during the application development. For example we extend some classes creating some derived classes! It would be great if the new derived class would work as well without replacing the functionality of the classes Otherwise the new classes can produce undesired effects when they are used in existing program modules.
Child classes should never break the parent class type definition
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. ( I have copied it just to give an actual bookish language)
Now let’s go realistic: Subtypes must be the substitute of their base class (derived types must be completely substitutable for their base types)
We have to make sure there will be no problems using the subtype or the original class
We can achieve it with the template design pattern (I’ll be discussing it in a future blog).
It is not independent of the Open-Closed Principle + interface segregation principle. The violation of the Liskov principle is a latent violation of the Open-Closed Principle!
Interface Segregation Principle:
This is the simplest of all. If an interface contains too many methods and we do not usually need them all in every class.
We can break that interface into many or two.
When we can, we must break our interfaces to meet the client's needs.
Dependency Inversion Principle:
What is the motivation?
When we develops the software or an application we usually creates the low level modules and the high level modules. BUT THIS IS NOT GOOD. What now if I want to replace the low level module. The whole code from low level to high level will require changes now.
Solution: The high level modules should not depend on high level module. A very easy catch in java is ‘new’ keyword. If. you are using a new keyword in a class the upper class is dependent on the lower class which you are intentiating.
HIGH LEVEL MODULES ←-> ABSTRACT LAYER (INTERFACES) ←-> LOW LEVEL MODULES !!!
This principle it the difficult one, but the most important one.
high-level modules should not be dependent on low-level modules.
Both modules should depend on abstractions ( interfaces I like the most).
Abstraction should not dependent on details, should dependent on Abstraction.
For Example….
Car car = new Car();But that’s not a good practice.
Create a Vehicle interface
Vehicle car = new Car();
In the next blog, I’ll be going through the design patterns in java.
