S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob.
These principles, when combined together, make it easy for a programmer to develop software that are 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
S – Single-responsiblity principle: A class should have one and only one reason to change, meaning that a class should have only one job.
for example, An AreaCalculator class for calculating area for different shapes such as circle, rectangle etc. The output method of AreaCalculator class should only sum the areas of the provided shapes, it should not care whether the user wants the output in JSON or HTML or XML. To achieve a SumCalculaterOutputter class is used this to handle.
O – Open-closed principle : Objects or entities should be open for extension, but closed for modification.
This simply means that a class should be easily extendable without modifying the class itself.
for example, A method Sum on the AreaCalculator class is required to be able to sum the areas of more shapes, we would have to add more if/else blocks which goes against the Open-closed principle. Another method is to define the sum in the shape class and each shape will need to implement the interface. In the sum method of AreaCalculator class, we can check the shapes provided are actually instances of ShapeInterface and calculate the area.
Liskov substitution principle
This means that every subclass/derived class should be substitutable for their base/parent class.
For example Child classes must not 1)remove base class behavior 2)Violate base class invariants.
And in general must not require calling code to know they are different from their base type.
Interface segregation principle
A client should never be forced to implement an interface that it doesn’t use
for example, if there are two methods area() and volumne() in the shapeInterface, the shapes like cubes and need not be implement volume() because they dont have. To achieve this we have to create another ManageShapeInterface and implement it on both the flat and solid shapes.
Dependency Inversion principle
It states that the high level module must not depend on the low level module, but they should depend on abstractions
Reference:- https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
Papooze 