S.O.L.I.D Principles

S.O.L.I.D is a group of five object-oriented design (OOD) principles (rules) that should be followed when designing software. SOLID was promoted by Robert C. Martin but the name itself was created by Michael Feathers.

These 5 principles have changed the way that we write software, it allows programmers to write code better, easier to understand and change later.

SOLID stands for:

• S   -   Single-responsibility Principle
• O   -  Open-closed Principle
• L   -   Liskov Substitution Principle
• I    -   Interface Segregation Principle
• D  -    Dependency Inversion Principle

01.Single-Responsibility Principle

“A class should have one and only one reason to change, meaning that a class should have only one job”

Let's see a few of its benefits:

• Testing – A class with one responsibility means few test cases are required.
• Lower coupling – A single class will have Few dependencies because of Less functionality.
• Organization – Smaller, well-organized classes are easier to use than complex/un-organized  ones.

02.Open-Closed Principle

“Objects or entities should be open for extension, but closed for modification”

For example:-

Imagine about a class that can use to calculate area of a circle/square.
What if we want to calculate area of a triangle?
We can extend that class and fulfill our requirement. But we shouldn’t be able to change it.

03.Liskov Substitution Principle

“Every subclass/derived class should be able to substitute their parent/base class”

For example :-

When extending a class it should perform all the basic functionaries of its parent class.

Child class should not have unimplemented methods(Parent’s methods)

Child class should not affect original methods after overriding.

04.Interface Segregation Principle

“Clients should not be forced to implement methods they do not use”

larger interfaces should be split into smaller ones. By doing so, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

Client’s should have the ability to implement only the methods that they.

05.Dependency Inversion Principle

Main idea behind this principle is that High-level modules, which provide complex logic, should be easily reusable and cannot be affect by the changes in low-level modules. So, we need to use abstraction to decouples high-level and low-level modules.