S.O.L.I.D Principles

The main aim of this article is to remind me about the SOLID Principle. I wrote articles on medium only to store all my knowledge about technology in one place.

So let’s discuss SOLID Principles, which is commonly asked in many interviews.

In software engineering, there are 5 principles intended to make software designs more understandable. These principles are made by Robert C. Martin.

SOLID Principles

S - Single Responsibility
O - Open Close Princlipes
L - Liskov Substitution
I - Interface Segregation
D - Dependency Inversion

Single Responsibility: The function should have a single responsibility.

Let’s take an example. If you have to arrange a birthday party. In the 1st picture if you single-handedly do everything then at the end you meshed up. But like this 2nd picture if you divide your work then you can do everything smoothly.

Like this in our project also, If a function or method has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.

Open-Closed: Function should be open for extension, but closed for modification.

In the below example 1st boy change the interior of one room and if the 2nd boy changes the color of the wall it may not match the expected outcomes.

But in the right side image, the 1st girl changes the interior and the other girl changes the other room’s interior then they can finish this work easily without any issue. It will not affect anyone.

Changing the current behavior of a Class will affect all the systems using that Class.

If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.

Liskov Substitution: If A is a subtype of B, then objects of type B in a program may be replaced with objects of type A without altering any of the desirable properties of that program.

In this below example if Alax is a child of Robin. He has to perform the task like his parent Robin because he inherits from Robin. If he is not able to give the same output he should be given some similar type of output. Like this example, he is not able to make maggie but he can make Yippee (which is similar to Maggie).

If the child Class doesn’t meet these requirements, it means the child Class is changed completely and violates this principle.

Interface Segregation: Team members should not be forced to depend on methods that they do not use.

Let’s discuss this principle. Here in the below example if your team member doesn’t aware of all of the technology any you forcefully give them an assignment. They face many issues and it may affect your project. Instead of doing this you can divide them by group and assign them some specific task.

Dependency Inversion: High-level modules should not depend on low-level modules. Both should depend on the abstraction.

In this below example you can see. 1st person is fully dependent on a particular tool but the 2nd person is flexible with many tools for designing the web page.

By using this principle we can reduce the dependency of a high-level Class (Class that executes an action with a tool) on the low-level Class (The class that is needed to execute the action) by introducing an interface.