Summary - SOLID Principle

Single Responsibility Principle

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

How does this principle help us to build better software? Let's see a few of its benefits:

  1. Testing – A class with one responsibility will have far fewer test cases.
  2. Lower coupling – Less functionality in a single class will have fewer dependencies.
  3. Organization – Smaller, well-organized classes are easier to search than monolithic ones.

Open Closed Principle

Objects or entities should be open for extension but closed for modification. In doing so, we stop ourselves from modifying existing code and causing potential new bugs.

Liskov Substitution Principle

If class A is a subtype of class B, we should be able to replace with without disrupting the behavior of our program.

Interface Segregation Principle

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.

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.

Dependency Inversion Principle

The principle of dependency inversion refers to the decoupling of software modules.

This way, instead of high-level modules depending on low-level modules, both will depend on abstractions.