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?
Barbara Liskov (born November 7, 1939, as Barbara Jane Huberman) is an American computer scientist who is an Institute Professor at the Massachusetts Institute of Technology and Ford Professor of Engineering in its School of Engineering’s electrical engineering and computer science department. She was one of the first women to be granted a doctorate in computer science in the United States and is a Turing Award winner who developed the Liskov substitution principle.
Source – Wikipedia
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 🙂
