In software engineering, SOLID is a mnemonic acronym for five design principles intended to make object-

oriented designs more understandable, flexible, and maintainable. The principles are a subset of many
principles promoted by American software engineer and instructor Robert C. Martin first introduced in his
2000 paper Design Principles and Design Patterns.
The SOLID principles focus on writing sustainable code—code that you can maintain as it grows.
The SOLID ideas are:

1. The single-responsibility principle: "There should never be more than one reason for a class
to change." In other words, every class should have only one responsibility.
Let's begin with the single responsibility principle. As we might expect, this principle states that a class
should only have one responsibility. Furthermore, it should only have one reason to change.
How does this principle help us to build better software? Let's see a few of its benefits:

1. Testing – A class with one responsibility will have far fewer test cases.
2. Lower coupling – Less functionality in a single class will have fewer dependencies.
3. Organization – Smaller, well-organized classes are easier to search than monolithic ones.

2. The open–closed principle: "Software entities ... should be open for extension but closed for
modification."
It's now time for the O in SOLID, known as the open-closed principle. Simply put, classes should be open for
extension but closed for modification. In doing so, we stop ourselves from modifying existing code and
causing potential new bugs in an otherwise happy application.
Of course, the one exception to the rule is when fixing bugs in existing code.

3. The Liskov substitution principle: "Functions that use pointers or references to base classes
must be able to use objects of derived classes without knowing it."
The Liskov principle states that you should design your class hierarchy such that the objects of a superclass
should be replaceable with objects of its subclasses without breaking the code.

4. The interface segregation principle: "Clients should not be forced to depend upon interfaces
that they do not use."
The fourth principle in the series is the interface segregation principle. As apparent from its name, the
principle advocates that your interfaces should be discrete, and classes should not implement interfaces
that contain methods irrelevant to them. In more sophisticated terms, clients should not have to depend
upon interfaces that they do not use.
This principle is an extension of the single responsibility principle, just for interfaces. The main goal of this
principle is to break down the application interfaces into smaller ones and eliminate the side effects of
large, singular interfaces with redundant elements. While it takes more time to design such structures, its
benefits are manifold.

5. The dependency inversion principle: "Depend upon abstractions, [not] concretions."

The dependency inversion principle dictates that you should create higher-level modules of a codebase in
such a way that they are reusable and unaffected by any change in other low-level modules. To achieve
this, abstraction has to be introduced that decouples the higher-level modules from the lower-level
modules.
The Dependency Inversion principle achieves this by two rules:
High-level modules should not directly depend on the low-level modules; instead, both of these
should depend on abstractions such as interfaces that link them.
The abstractions in a codebase should not depend on the details of the code. Instead, the details
should depend on the abstractions implemented in the code.
Dependency Injection (DI) is a popular technique that provides the indirection needed to avoid depending
on low-level details and coupling with other classes. Dependency Injection forces classes to rely on a
higher-level abstraction of their dependencies, thereby removing the hard coupling between two exact
classes.