A Simple Guide to SOLID Design Principle

What is the SOLID Design Principle?

As the name suggests, let’s see what SOLID stands for in SOLID Design Principle –

S	Single Responsibility
O	Open/Closed
L	Liskov Substitution
I	Interface Segregation
D	Dependency Inversion

SOLID stands for Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency inversion. If you follow this pack of 5 SOLID design principles you will build robust and easy-to-maintain software.

S – Single Responsibility

A class should have only one responsibility, which means, it should have only one reason to make any changes in future

Benefits

• Better Unit Testing – A class with single responsibility will have fewer test cases
• Loose Coupling – A class with single responsibility will have less functionality and hence less or no dependency
• Better Organization – A class with single responsibility will be easier to organize and maintain because it will be smaller or contained in terms of size or line of code

Example Scenarios

Sending an email, Logging, and report printing are some examples of the SRP (Single Responsibility Principle)

O – Open/Closed

A class should be open for extension but closed for modification.

In simple words, by following this principle, we safeguard a stable class by avoiding any modification which may cause an unwanted regression in the existing functionality.

Benefits

• Avoid regression defects by not modifying an existing stable class functionality
• Better code maintenance
• Extending a class is given priority which gives you more control over the inheritance concept of OOPS

Example Scenarios

Data structure classes like the stack, queue, list, etc. Stable SRP classes. JPA Layer implementations.

L – Liskov Substitution

If class S is sub-type of class T, then an object of type T may be substituted with any object of type S without impacting any existing behavior of the program

Perplexed? It’s OK, this is the most complex design principle until you get a hang of it. so don’t worry! Let’s understand through some example and description

Who is Liskov?

Okay, Let’s understand this one by reverse engineering method i.e. bottom –> top approach. Let’s Watch these videos to understand more –

Hope the above videos give a clear explanation of Liskov’s substitution principle. Take it easy, don’t take too much stress on understanding the definition. Once you are able to understand the example from the video, try to map its understanding to the definition. Take your time.
Drop in any comments or queries you might still have in the comment section of this page.

Another quick video that explains a bit deeper.

I – Interface Segregation

Larger interface should be segregated into smaller set of specific interfaces. No client should be forced to depend on methods it doesn’t use.

In simple words, only those methods should be added to an interface that is specific to the original functionality for which the interface is being created. This is in fact a way of achieving Liskov’s substitution principle.

Benefits

• Highly decoupled system
• Easy refactoring of code-base
• Helps in achieving Liskov’s substitution strategy

Example Scenarios

You create a Restaurant interface and put in all methods related to online orders, walk-in orders, and service orders. Your online API consumers would not be using the walk-in and the service orders methods and vice versa. There is a violation of the Interface segregation principle here and it should be addressed appropriately.

D – Dependency Inversion

High level module should not depend on low level modules. Both should depend on abstraction

In simple words, this principle says that when you create a high-level class that is going to rely on the implementation of the low-level class, it is better to introduce abstraction to remove dependency among the modules and also the open/close principle is safeguarded at the same time.

Let’s take a look at the explanation and examples in the following video by

Benefits

• Easy to understand and maintain code
• All benefits of the open/close principle
• Easy Testing
• Loosely coupled modules

Further Readings

• https://en.wikipedia.org/wiki/SOLID
• Check out our other blogs on Design Patterns & Design Principles

Feel free to share your thoughts on this topic in the comments section below 👇 We would be happy to hear and discuss the same 🙂

Spread the word!