What is solid principle

https://medium.com/@mari_azevedo/s-o-l-i-d-principles-what-are-they-and-why-projects-should-use-them-50b85e4aa8b6
https://medium.com/better-programming/solid-principles-simple-and-easy-explanation-f57d86c47a7f

S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design theorized by our beloved Uncle Bob (Robert C. Martin) by the year 2000. The author Michael Feathers was responsible for creating the acronym:

[S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

Single Responsibility Principle:

A class should have one, and only one, reason to change.

One class should serve only one purpose. This does not imply that each class should have only one method, but they should all relate directly to the responsibility of the class. All the methods and properties should work towards the same goal. When a class serves multiple purposes or responsibilities, it should be made into a new class.

Open-Closed Principle:

Entities should be open for extension, but closed for modification.

Software entities (classes, modules, functions, etc.) should be extendable without actually changing the contents of the class you’re extending. If we could follow this principle strongly enough, it is possible to then modify the behavior of our code without ever touching a piece of the original code.

Liskov Substitution Principle:

The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote “Data abstraction” in 1987. 

Robert Martin made the definition smoother and more concise in 1996:

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.

Or simply: Subclass/derived classes should be substitutable for their base/parent class.

It states that any implementation of an abstraction (interface) should be substitutable in any place that the abstraction is accepted. Basically, it takes care that while coding using interfaces in our code, we not only have a contract of input that the interface receives, but also the output returned by different classes implementing that interface; they should be of the same type.

Interface Segregation Principle:

A client should not be forced to implement an interface that it doesn’t use.

This rule means that we should break our interfaces into many smaller ones, so they better satisfy the exact needs of our clients.

Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to minimize side consequences and repetition by dividing the software into multiple, independent parts.

Make fine grained interfaces that are client specific.

Dependency Inversion Principle:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Or simply: Depend on abstractions, not on concretions.

By applying the Dependency Inversion Principle, the modules can be easily changed by other modules just changing the dependency module. Any changes to the low-level module won’t affect the high-level module.