S.O.L.I.D

2 min readMar 7, 2021

S.O.L.I.D is an acronym used in software engineering that describes a set of principles of object-oriented design. When a system is implementing by using these principles, the codebase is understandable, reusable, testable, maintainable and flexible. The concept originated from Robert C. Martin. It has been adopted and used amongst software engineers ever since.

S.O.L.I.D stands for

Single-responsibility principle (SRP)
Open-closed principle (OCP)
Liskov substitution principle (LSP)
Interface segregation principle (ISP)
Dependency inversion Principle (DIP)

Single-responsibility principle (SRP)

This principle states that a class should only have a single responsibility.

It means each class, method, or service should have only one responsibility. In simple words, a method, class or service should have only one job to complete.

Assume that you have a class called Shape to calculate area of a shape and you want to convert the result into JSON format. If both logics are handled by the Shape class, it violates the single responsibility principle. The shape class should handle only one task either calculating area of a shape or converting result into JSON.

Open-closed principle (OCP)

This principle states that a class should be extendable, but closed to modification. That simply means any desired additional behavior should be added to another class that extends your original class instead of modifying it.

Liskov substitution principle (LSP)

This principle states that a derived class must be substitutable for its base class.

It means objects of the parent class/super class should be replaceable with the objects of its child class without breaking the operation. All the sub classes/child classes should have all the methods in the parent class, and unique methods for sub classes.

Interface segregation principle (ISP)

This principle states that client-specific interfaces are better than one general-purpose interface.

Suppose that Shape class has draw() method and colorize() methods. But client wants to use draw() method only. So that we are not going to implement colorize() method for that particular client.

Dependency inversion Principle (DIP)

Higher level modules should not depend on lower level modules, but they should depend on abstraction.

Abstraction must not depend on the details, but the details should depend on abstraction. A change of a one level should not affect to other layers.

High level modules have one reason to change, and closest destination. It is the top most layer.

eg : 3-tire architecture, n-tire architecture