In this article, we'll introduce you to the SOLID Principals and make light on their importance in designing better software.
Definition
A design principal helps us to create more maintainable, understandable and flexible software. Therefore, as our applications grow, we can reduce their complexity and save a lot of efforts by having easy and more understandable code.
Each character of SOLID stands for a principal, they are not applicable separately. In the following sections we will explore all the five principals.
1- Single Responsibility Principal (SRP).
This principal says that class should do one thing and do it well, {if it has a reason to change it should be one reason. Its purpose is to have simple classes with lower dependencies}.
For example, let's take a look at the following class:
Till now, this class respects the SRP. However, if we have a new requirement and we need to send notifications to an Employee, the right way to do it is to create a NotificationService, so our classes stay simple with a single responsibility. For further reading, I suggest you take a look to Responsibility Driven Design (RDD).
2- Open Closed Principal (OCP).
A software module should be Open to extension and Closed for modification. The goal of this principal is to avoid modifying an existing working code unless to fix bugs, and make it open to extension in case of an improvement.
Take a look at the following class:
Car class works perfectly, but after a while we decided to handle Electrical Cars. To do so, we can modify Car class which break OCP because we will add changes to a working code. The right way to do it is to extend from Car:
3- Liskov Substitution Principal (LSP).
This principal says that a subclass could be replaced with a superclass without breaking our code. The following example clarify the LSP:
Class Vehicle has two subclasses, Car and Truck, on the other hand, we have VehicleWorkshop class which is used by Vehicle. This architecture is respecting the LSP by reason of the Vehicle Workshop could repair both Car and Truck.
Now, let's have another class called CarDriver. If we use it directly with Vehicle, Truck can't replace Vehicle because CarDriver doesn't drive Trucks which breaks the LSP. In this case, we should associate CarDirver directly with the Car class.
4- Interface Segregation Principal(ISP).
The Interface Segregation Principal(ISP) says when we have a large interface we need to split it into multiple interfaces, so the implementing classes won't be forced to implement methods they don't need. Let's explore the following example:
We want our DeveloperService class and HRService to implement it. What we notice, that a developer doesn't organize interviews and an HR employee can't make a software: Violation of the ISP. So, the solution is to split the IEmployee into two different interfaces.
5- Dependency Inversion Principal (DIP).
The last principal is Dependency Inversion Principal (DIP), to respect it we need to make software modules depend on abstraction, which means decoupling between classes.
Let's jump again to an example to understand, for this principal we will have the following class :
A Driver has a name and a Car to drive. Our software is working fine, but we got an improvement: The Driver will be driving a Truck instead. In this case, we'll be forced to modify the existing code (OCP not respected). To fix this mess we'll replace Car with an abstraction(DIP), Vehicle Interface:
Implementing this solution makes our code flexible and scalable.
Conclusion.
In this article, we've explained Solid Design Principals with some examples, Also we mentioned their importance in building more scalable and maintainable software.
Some links and references:
