S.O.L.I.

D is an acronym for the first five object-oriented design(OOD)**

principles** by Robert C. Martin,

These principles, when combined together, make it easy for a programmer to

develop software that is easy to maintain and extend. They also make it easy
for developers to avoid code smells, easily refactor code, and are also a part of
the agile or adaptive software development.

S.O.L.I.D stands for:

When expanded the acronyms might seem complicated, but they are pretty
simple to grasp.

 S - Single-responsiblity principle
 O - Open-closed principle
 L - Liskov substitution principle
 I - Interface segregation principle
 D - Dependency Inversion Principle

Single-responsibility Principle
S.R.P for short - this principle states that:

A class should have one and only one reason to change, meaning that a class
should have only one job. When requirements change, this implies that the
code has to undergo some reconstruction, meaning that the classes have to be
modified. The more responsibilities a class has, the more change requests it
will get, and the harder those changes will be to implement. The
responsibilities of a class are coupled to each-other, as changes in one of the
responsibilities may result in additional changes in order for the other
responsibilities to be handled properly by that class.
Open-closed Principle
Objects or entities should be open for extension, but closed for modification.
You should be able to extend a class’s behaviour, without modifying it. This
principle is the foundation for building code that is maintainable and reusable.

Liskov substitution principle

Derived classes must be substitutable for their base classes.
What is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behaviour of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.

Interface segregation principle

A client should never be forced to implement an interface that it doesn't use
or clients shouldn't be forced to depend on methods they do not use. Make
fine grained interfaces that are client specific.Clients should not be forced to
implement interfaces they do not use. In other words, it is better to have many
smaller interfaces, than fewer, fatter interfaces.

Dependency Inversion principle

The last, but definitely not the least states that:

Entities must depend on abstractions not on concretions. It states that the

high level module must not depend on the low level module, but they should
depend on abstractions.

Depend on abstractions, not on concretions.

A. High level modules should not depend upon low level modules. Both should
depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon
abstractions.