Software Design (SOLID) Principles

SOLID
S – Single-responsibility principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle

Single Responsibility Principle (SRP)
A class should have a single reason to change, meaning that class should have only one job. If we have 2 reasons to change for a class, we have to split the functionality in two classes.
Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

The Open-Closed Principle (OCP)
A software module (classes, functions and modules) should be open for extension and closed for modification. Consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it.
This principle is applicable when you change the software but it should support backward compatibility, regression testing etc.
Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior.
Some particular cases of OCP are Template Pattern and Strategy Pattern.

Liskov’s Substitution Principle (LSP)
Subtypes must be completely substitutable for their base types.
Make sure that new derived classes are extending the base classes without changing their behavior.
New derived classes should be able to replace the base classes without any change in the code.

Interface Segregation Principle (ISP)
Many specific interfaces are better than a single general interface.
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.
Add only methods to an interface that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.
Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

Dependency Inversion Principle
I Don't Care How, Just Give Me What I Want
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.
Also known as “Inversion of Control”.
Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.