The Solid Principles are the principles that allow us to manage most of the software design problems.

These are the basic principles that should be followed during the development of an application.

This helps us to avoid problems arising during the development of an application.

This was first introduced by Michael Feathers

The Problems that arise due to not using Solid principles are:

1. To give more and more responsibilities to the same class

2. Making classes depend on each other and changes in one class can lead to many problems

3. By using duplicate code many times in an application

4. Tight coupling can make any new addition of functionality or Fixing bugs into creating some unknown issues

5. We can also end up with a code that is not testable

The SOLID Principles can help us to:

1. Achieve reduction of code

2. Make the code more readable, extensible, and Maintainable

3. Reduce errors and Implement Reuse-ability

SOLID Stands for:

S -> Single Responsibility Principle (SRP)

O -> Open closed Principle (OSP)

L -> Liskov substitution Principle (LSP)

I -> Interface Segregation Principle (ISP)

D -> Dependency Inversion Principle (DIP)

Let's go Deep into Solid Principles and Understand it

Single Responsibility Principle (SRP)

"A class should have only one reason to change"

Every Module or class should have the responsibility for a single part of the functionality provided by the software and it should all be encapsulated by the class.

Open closed Principle (OSP)

"Software Entities should be open for extension but closed for modification"

The design should be in such a way that by adding new functionality like new classes and keeping the existing code unchanged.

Liskov substitution Principle (LSP)

"Object in a program should be replaceable with instances of their sub-types without altering the correctness of the program"

If a class is using a base class, the base class be replaced by the derived class without affecting the program of the module.

Interface Segregation Principle (ISP)

"Many Clients Specific Interface is better than one General purpose interface"

We should not enforce clients to implement interfaces that they don’t use. Instead of making one big interface, we can break it into a smaller interface.

Dependency Inversion Principle (DIP)

"One should depend upon abstractions [not] concretions"

This means that the high-level module should not depend on low-level modules.

We will gain a further understanding of the principles in the Upcoming Blogs.

Thank you for reading