🚀 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:

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:

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

Follow me On Hashnode

Checkout more Portfolio