What are the 5 SOLID principles in Object Oriented Design and How we can achieve the technical problems in best possible way

5 SOLID principles in object-oriented design

Robert C. Martin introduced the 5 SOLID principles in object-oriented design [OOD]. These principles were established to development of the software and maintain its project growth. 

SOLID stands for:

• S - Single-responsibility Principle
• O - Open-closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle 

The following article introduces those SOLID principles, for your better understanding and development to make you a better developer.

Single responsibility Principle [SRP]

SRP states,

'A class should have one and only one reason to change, meaning that a class should have only one job.'

Single Responsible principle says that each and every class in a computer program should be responsible for a single part of that program's functionality which should be encapsulated. All the classes in that function or class should be narrow with the responsibility.

According to Martin when responsibility is a reason to change, it should be concluded that a class should have one and only one reason to be changed.

For example, consider a class that compiles and prints an article. Think of a class that can be changed for two reasons. First, the format of the article change, and then secondly content of the article change. The changes of these two classes having don't affect each other. According to the Single Responsible principle, these two parts are really two separate responsibilities, and therefore these two classes should be separated. If we don't concerned about having two classes for these two responsibilities then the robustness of the program in danger.

Therefore having a Single Responsible principle in a design is ensure your good coding practice.

Open-Closed Principle

Open-Closed Principle states,

'Objects or entities should be open for extention but closed for modification.'

Open - Closed Principle's simple meaning is that the functions and the class should not be modified when we need to develop a new feature. Rather than modifying it, we should be extended the entities. This principle requires that the class should be open for extension and closed for modification.

So this principle says that without touching existing code in the class we should be able to add new functionality. The reason for not touching the existing code is that because when we modifying the existing code, we are taking risks while we creating new potential bugs.  So we should always try to avoid reliable and already tested code as much as possible.

Because of this Open-Closed principle if you ask how we going to add new functions without an existing class, then the answer is it can be done with help of abstract classes and interfaces.

Liskov Substituion Principle

Liskov Subs Principle states,

'Every subclass or derived class should be substitutable for their base or parent class.'

Think about given that class A is a superclass of B, and we should be able to pass an object of class B to any method that expects an object of class A and the most important method shouldn't give any weird output in that case.

When using the Liskov substitution principle, 

1. Child class performs basic functionalities of the base class when extending a class.   
2. Child class should have all methods in the base class.
3. Child class should not give a different meaning to the methods that existing in the base class after overriding them.

Remember this is expected behavior because when we inherit superclass for a child class we assume that child class inherits everything that superclass has. So, that means child class extends the behavior but never narrows it down.

Therefore it's very important to follow this principle because, if not it will lead to some nasty bugs that are hard to perceive.

Interface Segregation Principle

Interface Segregation Principle states,

'A client should never be forced to implement an interface that it doesn't use, or client should be forced to depend on methods they do not use.'

Keeping things separated means Segregation and the Interface Segregation Principle is all about separating the interfaces.

So, this principle says the many client-specific interfaces are better than one general-purpose interface. It's most important to remember that clients should not be forced to implement the functions that they do not need.

Dependency Inversion Principle

Dependency Inve Principle states,

'High- level module must not depend on the low-level module, but they should depend on abstractions. Entites must depend on absrations, noton concretions. '

That means,

• High-level modules should not depend on low-level modules. But both should depend on the abstractions.
• Abstractions should not depend on details. Details should depend upon abstractions.

How we can achieve the technical problems in the best possible way

There are some solutions to achieve the technical problems in the best possible way. There are, 

• Think throughout the problem
• Divide and conquer
• KISS - [Keep it simple and stupid]
• Learn, especially from mistakes
• Always remember why software exists
• Remember that is not the user