SOLID Principles

Table of contents

Automate your business at $5/day with Engati

Switch to Engati: Smarter choice for WhatsApp Campaigns 🚀
SOLID principles

What are SOLID principles in programming?

SOLID principles are the set of software design principles used by software engineers in object-oriented software development to follow, scale and maintain a proper structure to the codes & programming. SOLID is a popular set of SOLID is an acronym that stands for five key design principles: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle.

The SOLID principles were developed by Robert C. Martin in a 2000 essay, “Design Principles and Design Patterns,” although the acronym was introduced later by Michael Feathers. As successful software changes, it becomes increasingly complex. Software becomes rigid, fragile, immobile, and viscous without good design principles. The SOLID principles were developed to combat these problematic design patterns.

What is the importance of SOLID principles?

These five principles help us understand the need for certain design patterns and software architecture in general. SOLID principles aim at reducing the dependencies of software engineers. As if they know and understand the basic architecture & design principles, it'll be easier for them to change or edit codes and alter a few changes if required. 

Additionally, SOLID principles enable engineers to make designs easier to understand, maintain, and extend. Ultimately, using these design principles makes it easier for software engineers to avoid issues and to build adaptive, effective, and agile software.

What is Object-oriented programming (OOP)? 

Object-oriented programming (OOP) is a modeling system and one of the classifications of programming languages built on the concept of "objects" which can contain data and code. Where "data" denotes fields, attributes, or properties and "code" is referred to as the methods or procedures. 

Object-oriented programming is about modeling a system as a collection of objects, which each represent some particular aspect of the system. Objects contain both functions (or methods) and data. An object provides a public interface to other code that wants to use it, but it maintains its private internal state: which means that other parts of the system don't have to care about what is going on inside the object. Object-oriented programming is faster and easier to execute and provides a clear structure for the programs. 

The SOLID Principles

S — Single Responsibility

O — Open-Closed

L — Liskov Substitution

I — Interface Segregation

D — Dependency Inversion

Single Responsibility

It states that a class should do one thing and therefore it should have only a single reason to change. If a Class 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. One potential change around database logic, logging logic, or attribute can affect the objects of a specific class. 

This means that if a class is a data container, like an Animal class or an Employee class, and it has some fields regarding that entity, it should change only when we change the data model. Generally, many teams work on the same project and edit the same class for different reasons, which could lead to incompatible modules and glitches. Hence, this principle focuses on assigning or adding single functions to class & objects. 



The Open-Closed Principle suggests that classes should be open for extension and closed to modification. Sometimes, we need to add certain functions to the existing class to perform additional tasks. So according to the Open-Closed Principle, We should add new functionality without touching the existing code for the class. This is because whenever we modify the existing code, we risk creating potential bugs. So we should avoid touching the tested and reliable (mostly) production code if possible. In simple words, this principle aims to extend a Class’s behavior without changing the existing behavior of that Class.

For Example: 


Liskov Substitution

The Liskov Substitution Principle works on the Inheritance mechanism, where a subclass inherits the features (fields and methods) of the parent class. As it's very important in Object-Oriented Programming to allow the reusability factor from the functionality perspective. The Liskov Substitution Principle states that subclasses should be substitutable for their base classes. Suppose class Bob is a subclass of class Alex, then we should be able to pass a function or an object of class Alex to class Bob to give the same outputs if needed. The important thing to take from dynamic languages is that if your program “promises” to do something, you need to keep to your promise and not surprise your clients.

Source: Medium 

Interface Segregation

Segregation means keeping things separated, and the Interface Segregation Principle is about separating the interfaces. The principle emphasizes having one general-purpose interface rather than many client-specific interfaces. Clients should not be forced to depend on methods that they do not use. Because, when a Class is required to perform actions that are not useful, it is wasteful and may produce unexpected bugs if the Class cannot perform those actions. It is advisable for software engineers to start by building a new interface and then let the class implement multiple interfaces as needed rather than using an existing interface and adding new methods.

Source: CodeCraft

Dependency Inversion

Let's understand these terms before getting ahead with the Dependency Inversion Principle: 

High-level Module(or Class): Class that executes an action with a tool.

Low-level Module (or Class): The tool that is needed to execute the action.

Abstraction: Represents an interface that connects the two Classes.

Details: How the tool works. 

The Dependency Inversion principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions. This means that developers should depend on abstractions, not on concretions. It also instructs that high-level module should not depend upon low-level modules. And, abstractions should not depend on details, but Details should depend upon abstractions.

Source: SpringFrameWork

Close Icon
Request a Demo!
Get started on Engati with the help of a personalised demo.
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
*only for sharing demo link on WhatsApp
Thanks for the information.
We will be shortly getting in touch with you.
Oops! something went wrong!
For any query reach out to us on
Close Icon
Congratulations! Your demo is recorded.

Select an option on how Engati can help you.

I am looking for a conversational AI engagement solution for the web and other channels.

I would like for a conversational AI engagement solution for WhatsApp as the primary channel

I am an e-commerce store with Shopify. I am looking for a conversational AI engagement solution for my business

I am looking to partner with Engati to build conversational AI solutions for other businesses

Close Icon
You're a step away from building your Al chatbot

How many customers do you expect to engage in a month?

Less Than 2000


More than 5000

Close Icon
Thanks for the information.

We will be shortly getting in touch with you.

Close Icon

Contact Us

Please fill in your details and we will contact you shortly.

This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
Thanks for the information.
We will be shortly getting in touch with you.
Oops! Looks like there is a problem.
Never mind, drop us a mail at