S — In the SOLID principle
Hi friends, In this post, I will explain the SOLID principle.
PART 1
In part 1, I will explain the S — Single Responsibility principle in the SOLID principles.
What is the SOLID principle?
The SOLID principle is the acronym of five principles indented to make Object-Oriented designs more flexible, understandable and maintainable.
The SOLID principle is for identifying badly designed code. This principle helps to write better code in object-oriented programming.
S — Single Responsibility Principle (SRP)
It says every software component should have only one responsibility. Here software components can refer to a class, method or module.
Real-world example: Look at a Swiss knife, it has various tools in it. But only one knife we needed. Based on the usage of a knife we can separate it.
How to separate one from another?
There is a principle called cohesion & coupling. Using this principle we can separate our software components.
Cohesion:- it is the degree to which the various parts of a software component are related.
Real-world example: First we see unsegregated garbage. Then we can segregate them into Plastic, Metal, and Paper. We can put all Plastic into one bag, Metal into another one, etc.
Coupling: It is defined as the level of interdependency between various software components.
Real-world example: Tarins are tightly coupled with tracks because the width of the train and track size should be compatible then only a train can move. It is needed for the railway system but it is an undesirable feature in Software development. Why? As a backend developer, we split our code router, controller, service, and model.
Our student service is responsible for students' data. But it has details of Save students' value in DB. Here we wrote code for access DB. This type of coupling is not needed.
Loose coupling helps attain better adherence to the Single Responsibility Principle. We need to consider another thing that is a reason to change the component.
Reason to change: Every software component should have one and only reason to change.
Example: Our student service has details of student object and save student details in the DB. Now it is deployed in production. There is a possibility to update the student service later. The can client request the developer to add a new field in the student object, and the technical team can suggest changing to the new DB(SQL to NoSQL). In this scenario, we are going to make two changes. The principle says every software component should have one and only reasons to change, But here we have two changes. Too many changes lead to bugs and hard-to-test entire things again. How can we avoid this? For this, we need to move the saving to the DB feature in a separate service called StudentRepository. Now we have two separate services.
Code Example:
class ValidatePerson {
constructor(name, age) {
this.name = name;
this.age = age;
}
ValidateName(name) {
if (name.length > 3) {
return true;
} else {
return false;
}
}
ValidateAge(age) {
if (age > 18) {
return true;
} else {
return false;
}
}
Display() {
if (this.ValidateName(this.name) && this.ValidateAge(this.age)) {
console.log(`Name: ${this.name} and Age: ${this.age}`);
} else {
console.log('Invalid');
}
}
}The above code has inconsistency. ValidatePerson has three methods ValidateName, ValidateAge, Display. In these three methods, Displaymethod is not relevant to ValidatePerson class, Because ValidatePerson class should have one purpose which is to validate the object not needed to Display the object.
So based on the Single Responsibility principles, we need to split into two separate classes.
export class ValidatePerson {
constructor(name, age) {
this.name = name;
this.age = age;
}
ValidateName(name) {
if (name.length > 3) {
return true;
} else {
return false;
}
}
ValidateAge(age) {
if (age > 18) {
return true;
}
return false;
}
}Create a file called validate-person.js and paste the above code.
import { ValidatePerson } from './validate-person.js';
class DisplayPerson {
constructor(name, age) {
this.name = name;
this.age = age;
this.validate = new ValidatePerson(this.name, this.age);
}
Display() {
if (
this.validate.ValidateName(this.name) &&
this.validate.ValidateAge(this.age)
) {
console.log(`Name: ${this.name} and Age: ${this.age}`);
} else {
console.log('Invalid');
}
}
}
const displayPerson = new DisplayPerson('Edison', 26);
const displayPerson1 = new DisplayPerson('Edison', 10);
displayPerson.Display();
displayPerson1.Display();Create a file display.js and paste the above code. In the above code, we instantiate ValidatePerson class inside the DisplayPerson class constructor. Inside the Display method we validate Name and Age.
The Single Responsibility principle helps to write better maintainability code.
In the next post, I will explain the following principle.
