Solid Principles In OOP

Solid design principles are a set of rules in OOP programming that if followed, help programmers write clean reusable, and maintainable code. It is possible to write a clean code in any OOP language without using the SOLID Principle but when there is a bug or an update needed, it takes more time to update and maintain such code because, without the SOLID principle, classes in OOP will be overloaded with multiple responsibilities and a slight change in such code will affect every other part of the entire structure giving the programmer a lot of bugs to be resolved.

The solid design principle is an Acronym that defines all the principles of design and is listed below:

S: Single responsibility principle

O: open-closed principle

L: Liskov substitution principle

I: Interface Segregation Principle

D: Dependency Inversion Principle

Single Responsibility Principle: This principle states that a class must have only one reason to change. A class should not have more than one purpose or one responsibility. The single responsibility principle is easily implementable when the purpose of the application is identified. This helps the design of the application and also identifies each and every class to be defined so that we can map out their implementation. The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change. A good separation of responsibilities is done only when we have the full picture of how the application should work. Let us check this with an example.

Open-Closed Principle: This principle states that a class must be opened to extension but closed to modification. This means that a class can inherit from another class (inheritance) or from an abstraction i.e Interfaces or abstract classes but cannot be modified.

Liskov Substitution Principle: This means that you should be able to use a derived or child class and have it behave like a base or parent class without modifying the base class. This also means that a derived class must be able to behave like a parent class without actually modifying the behavior of the parent class.

Interface Segregation Principle: This principle states that clients should not be forced to use an interface they don't need. This is just like the single responsibility principle where a class is to have basically just one purpose, interfaces should be set up in smaller bits to suit a single purpose instead of one large interface with method definitions that are not needed. Every interface should be designed to fit the code that uses them and not the code that implements them. So the methods on the interface are defined by which methods the client code needs rather than which methods the class implements.

Dependency Inversion: This principle states that a High-Level class should not depend on a Low-Level class but instead should depend on Abstractions. The Low-Level class should depend on abstractions and the High-Level class should also depend on abstractions. Abstractions should also not depend on details but details should depend on abstractions.