# 🚀 SOLID Principles Series – Part 1: Single Responsibility Principle (SRP)

There is no better way to start off my post than introducing you to the **SOLID Principles** – a set of **five** **rules** that every **developer**, regardless of experience, needs to master in order to produce **clean, scalable, performance-oriented, and easy-to-maintain code**. With this in mind, allow me to introduce to you the S of SOLID: The Single Responsibility Principle (SRP).

## Single Responsibility Principle (SRP)

The **Single Responsibility Principle** states:

> “A class should have only one reason to change.” – *Robert C. Martin*

A class should only **do one task** and, ideally, have **one responsibility.** A class that consists of more than one responsibility has the potential to become coupled with multiple system aspects. This would mean that when a single responsibility changes, unexpected and unwanted bugs could arise.

---

## The Problem with Multiple Responsibilities

Imagine you're working with the **User** class in JavaScript:

```javascript
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  validateEmail() {
    // Validate email format
  }

  saveToDatabase() {
    // Logic to save user to DB
  }

  sendWelcomeEmail() {
    // Email logic
  }
}
```

This User Class Handler does **too much responsibilities**:

* It Validates user data
    
* It Handles persistence
    
* It Sends emails
    

Consider a scenario where you want to change the logic of email-sending — you have to change the User class which is unrelated to user data. This in itself violates SRP.

---

## Refactoring Using SRP

Let’s break responsibilities into focused classes:

```javascript
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserValidator {
  static validate(user) {
    // Check if user.email is valid
  }
}

class UserRepository {
  static save(user) {
    // Save to DB
  }
}

class EmailService {
  static sendWelcomeEmail(user) {
    // Send email
  }
}
```

Each class now has **only one reason to change**:

* `UserValidator` changes only if validation logic changes.
    
* `UserRepository` changes only if storage changes.
    
* `EmailService` changes only if email logic changes.
    

This is SRP in action!

---

## Why SRP Matters

Maintaining a system SRP compliant is bound to improve:

* ✅ **Better Maintainability** – Less change will improve unrelated broken functionality.
    
* ✅ **Improved Readability** – Focused and clear cut code will be far easier to read.
    
* ✅ **Simpler Testing** – Mocking and unit testing class is made easier by small class size.
    
* ✅ **Enhanced Reusability** – Independent use of each class without affecting the other improves reusability.
    

---

## Key Takeaways

* **One class = One responsibility.**
    
* **SRP** makes your code **cleaner**, **modular**, and more **testable**.
    

---

## What’s Next?

In the following sections of the series we will discuss the **Open/Closed Principle**, which teaches us how to design our code in a way that allows for easy extensibility but restricts alteration of existing code.

Follow along and stay tuned!

---

I hope you enjoyed this..! Feel free to share your thoughts, questions, or ideas for future topics in the comments.

> ***Thanks for reading***
> 
> ***Happy coding!***
> 
> ***If you enjoyed the article and would like to show your support, be sure to:***
> 
> ***Follow me On*** [***Medium***](https://kawaljain.medium.com/)
> 
> ***Follow me On*** [***Hashnode***](https://blog.kawaljain.com/)
> 
> ***Checkout more*** [***Portfolio***](http://kawaljain.com/)