What are the SOLID Principles?

These principles are a set of principles that ensure that the code we write is understandable, open to innovations, and minimally repetitive.

The purpose of these principles:

Quick adaptation of the code we write to new requirements in the future;
New features can be added without major changes to the code;
Avoiding code duplication.

S.O.L.I.D. principles are as follows:

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

Single Responsibility Principle — (Single responsibility principle)

The purpose of this principle is for a class or method to do something.

Codes can be written in a class for only one purpose, for example, let it be a class where we write CRUD operations, the purpose of this class is to hold CRUD operations only. we will violate the principle.

Open Closed Principle — (Open closed principle)

The purpose of this principle is that the class is connected to changes, but open to innovations. That is, our project should be open to innovations, but at the same time, our basic class should not be changed.

Liskov substitution principle — (Liskov's substitution principle)

The basic methods that will be the same in all classes are written in the base class, and the methods that will change depending on the situation are written in the interfaces and called when needed. Used to prevent unnecessary implements.

Interface segregation principle

This is to avoid clutter by cramming methods that do only one thing into an interface. In this principle, which is similar to the principle of single responsibility, the methods that do one job are written in an interface, so unnecessary methods are not called during the implementation.

Dependency inversion principle

According to this principle, upper-level classes, methods and modules should not depend on lower-level classes. Any changes made in lower classes should not affect upper classes.