WHY YOU SHOULD BE FOLLOWING THE SINGLE RESPONSIBILITY PRINCIPLE
Tags: programming, beginners
Published: 2021-03-27 21:39:50

For those of you already familiar with the SOLID Design Principles, this won't be much of a new thing. For newbies however

> SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

They are more like best practices rather than a rule. 

# SINGLE RESPONSIBILITY 
The S in SOLID.

It says

> A class should have one, and only one reason to change.

The goal is to separate behaviors or concerns. Everything has its own place and it should be placed there.

Basically 
1. Make smaller code modules (class/function etc) 
2. Module does a specific thing only and is liable for that only.
3. It is named precisely for what it does.

As opposed to Large Generic classes with different responsibilities and behaviors.

This pattern can be seen in other **SOLID** principles like **[Interface Segregation](https://dev.to/huzaifa99/is-it-practical-to-use-interface-segregation-principle-3ojl)** where we focus on making role-specific interfaces.

## A SIMPLE USE CASE
Let's say we are saving a random user's data to some database. This is what we would normally do inside a function(pseudocode-ish).
```javascript
function createUser(userData){
    // 1. validate user data for email and password keys
   
    // 2. check if the email is already registered

    // 3. save the user to DB 

    // 4. return saved user as a response
}
```
With the **SINGLE RESPONSIBILITY** approach we will make dedicated functions that would handle specific logic and be responsible for it only
```javascript
function validateUser(user){
    // will validate userObject for email and password keys
}

function isEmailRegistered(email){
    // will check if the email is already taken 
}

function saveUserData(user){
    // will save user data to db
}

function createUser(userData){
    validateUser(userData)
   
    if(isEmailTaken(userData.email)){
      // throw some error here
    }

    var user = saveUserData(userData)
    
    return user
}
```
This is a simple example but when dealing with multiple validations and complex logic this type of approach is really handy.

# WHY USE IT
Consider these 
1. Easy to follow and Understand
2. Debugging made easy
3. Removing and refactoring is much simpler than before. 
4. You can make bigger changes without fear. 
5. It is scalable and maintainable

Also when there is a time you need-to/have-to/want-to/are-forced-to make changes and have followed **SINGLE RESPONSIBILITY**, then it will be much quick and easy. 

What if you break something or there is a bug? Well, it is Easily traceable following this principle and if you break something, you break that one thing only, not an entire system.

Not to mention that this rule helps a lot in the implementation of other SOLID principles like **[Dependency Inversion](https://dev.to/huzaifa99/why-the-dependency-inversion-principle-is-worth-using-opj)** and the **[Liskov Substitution Principle.](https://dev.to/huzaifa99/is-the-liskov-substitution-principle-really-useful-3oce)**

### Tip
If you are someone that writes tests for their project then you would surely love this rule, it gives you predictable behavior and control.

---
Here it is guys, I hope I explained it in a simple and easy way. Do you use SOLID principles in your projects? Be sure to comment below.

### What's Next
Laern about **[Open/Close Principle](https://dev.to/huzaifa99/explained-open-close-principle-in-2-minutes-29dd)** Principle in 2 Minutes.