Becoming a better developer by using the SOLID design principles
There are 5 SOLID principles that were introduced by Robert C. Martin, named by Michael Feathers. I think these five principles highlight when code maintained by someone other than the original developer. At such a time reader must pay more time rather than the developer to write the code. This is not a good quality of a developer. Also, when we are working on a startup project it is better if we follow these steps for a better future. By the way, this is not a very essential concept, but it is better if we follow these 5 principles. If we are doing a group project, it will help the team to complete the project with less time, make the code maintainable, make it easy to add new functionalities or remove functionalities, etc. Here we are going to learn SOLID.
What are SOLID design principles?
“In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable.”
S — Single-Responsibility Principle
O — Open-Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle
Single-Responsibility Principle
“A class should have one and only one reason to change, meaning that a class should have only one job.”
If we implement multiple functionalities in a single class, that will complex our code and if future modification required, it would affect the whole class. If we use the Single responsibility principle, we can maintain our code easily.
As an example let’s consider an employee class that prints employee details printEmDetails(), Calculate their monthly salary bonus calculateBonus() and add those details to the employee database addEmDetails().
Employee.java
Employee.java violates the single responsibility principle. We can separate the above three functionalities into three separate classes using the single responsibility principle.
Employee.java
Bonus.java
DbEmployee.java
Open-Closed Principle
“Classes should be open for extension but closed for modification.”
As an example, let us consider a racing car class that has a model, color and body kit.
But later if the design team wants to upgrade the current racing car with a spoiler. But according to the Open-closed principle, we cannot do modifications to the class. Because if we do so, there will be some errors and it will affect the whole project. So, instead of modifying the same class, we can extend our racing car class.
Liskov Substitution Principle
“Derived classes must be completely substitutable for their base classes”
That means if class X is a subtype of class Y, then we should be able to replace Y with X without disrupting the behavior of a program. Barbara Liskov introduced this principle.
Let’s take an easy example to understand this principle. Consider there is a Car interface with engineOn() and accelerate() methods.
According to the above example, a driver can turn on the engine and increase the power by accelerating. Wait, what about electric cars? Electric cars do not have an engine so how can they accelerate an engine.
This violates Liskov substitution principle by putting a car without an engine. Therefore, the base class cannot be replaced by the derived class. So, substituting the base class with the derived class may result in unexpected behavior.
Interface Segregation Principle
“Larger interfaces split into smaller ones.”
Implementation classes use required methods only.
For this example, let’s consider we have to make a program to convert Celsius to Fahrenheit cToF(), Celsius to kelvin cToK(), and Fahrenheit to kelvin fToK(). So, let us create an interface named Convert which having three methods.
If we want to use the only cToF() and fToK() methods first we have to split our interface into 3 separate ones.
Now, we can Implement the two methods which we wanted.
Dependency Inversion Principle
“The principle of Dependency Inversion refers to the decoupling of software modules. This way, instead of high-level modules depending on low-level modules, both will depend on abstractions.”
Okay, let us go with an example to understand this principle. Can you imagine a Car without a tire and seat?
Now let us add tires and seats for the car. So, let us create a constructor of the class and add the instances of the tire and seat.
But by declaring tires and seats with the new keyword, we have tightly coupled 3 classes together. So it is hard to test the car class. Let us decouple the Car from the seats.
I hope you learnt something about SOLID principles from my story. Thank You.
