Single Responsibility Principle

Simplifying User Management in Scala: Embracing the Single Responsibility Principle

In the realm of software development, maintaining clean, maintainable, and modular code is paramount. One of the key principles that guide us towards this goal is the Single Responsibility Principle (SRP). The SRP states that a class should have one, and only one, reason to change. In simpler terms, each class should focus on a single responsibility.

Let’s embark on a journey to understand SRP with a practical example in Scala, transforming a monolithic user management system into a modular, maintainable one.

The Monolithic UserManager

Imagine we are tasked with building a user management system that handles user registration. Initially, we might be tempted to cram all related functionalities into a single class.

import java.util.regex.Pattern

class UserManager {
  def registerUser(username: String, email: String, password: String): Unit = {
    // Validate username
    if (username.isEmpty || username.length < 5) {
      throw new IllegalArgumentException("Invalid username")
    }

    // Validate email
    val emailPattern = Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$")
    if (!emailPattern.matcher(email).matches()) {
      throw new IllegalArgumentException("Invalid email")
    }

    // Validate password
    if (password.isEmpty || password.length < 8) {
      throw new IllegalArgumentException("Invalid password")
    }

    // Register user module (save to database)
    println(s"User registered: $username")

    // Send notification module
    println(s"Notification sent to: $email")
  }
}

object Main extends App {
  val userManager = new UserManager()
  userManager.registerUser("user123", "user@example.com", "password123")
}

At first glance, this UserManager class might seem convenient. However, it violates the Single Responsibility Principle by taking on multiple responsibilities: validation, registration, and notification. Such a design makes the class harder to maintain and test. Let's see how we can refactor this code to adhere to SRP.

Embracing SRP: A Modular Approach

To follow SRP, we need to break down the UserManager class into smaller, focused classes. Each class will handle a single responsibility:

1. UserValidator: Responsible for validating user data.
2. UserRepository: Responsible for registering the user (saving to the database).
3. NotificationService: Responsible for sending notifications.

Here’s the refactored code:

import java.util.regex.Pattern

// Responsible for validating user data
class UserValidator {
  def validateUsername(username: String): Unit = {
    if (username.isEmpty || username.length < 5) {
      throw new IllegalArgumentException("Invalid username")
    }
  }

  def validateEmail(email: String): Unit = {
    val emailPattern = Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$")

import java.util.regex.Pattern

// Responsible for validating user data
class UserValidator {
  def validateUsername(username: String): Unit = {
    if (username.isEmpty || username.length < 5) {
      throw new IllegalArgumentException("Invalid username")
    }
  }

  def validateEmail(email: String): Unit = {
    val emailPattern = Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$")
    if (!emailPattern.matcher(email).matches()) {
      throw new IllegalArgumentException("Invalid email")
    }
  }

  def validatePassword(password: String): Unit = {
    if (password.isEmpty || password.length < 8) {
      throw new IllegalArgumentException("Invalid password")
    }
  }
}

// Responsible for registering the user
class UserRepository {
  def saveUser(username: String, email: String, password: String): Unit = {
    // Simulate saving to a database
    println(s"User registered: $username")
  }
}

// Responsible for sending notifications
class NotificationService {
  def sendNotification(email: String): Unit = {
    println(s"Notification sent to: $email")
  }
}

object Main extends App {
  val validator = new UserValidator()
  val repository = new UserRepository()
  val notificationService = new NotificationService()

  val username = "user123"
  val email = "user@example.com"
  val password = "password123"

  // Validate user data
  validator.validateUsername(username)
  validator.validateEmail(email)
  validator.validatePassword(password)

  // Register user
  repository.saveUser(username, email, password)

  // Send notification
  notificationService.sendNotification(email)
}

Breaking Down the Responsibilities

By refactoring our code, we’ve achieved a clear separation of concerns:

1. UserValidator: This class encapsulates all the logic for validating the user’s input. It checks the username, email, and password according to our predefined rules.

class UserValidator {
  def validateUsername(username: String): Unit = {
    if (username.isEmpty || username.length < 5) {
      throw new IllegalArgumentException("Invalid username")
    }
  }

  def validateEmail(email: String): Unit = {
    val emailPattern = Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$")
    if (!emailPattern.matcher(email).matches()) {
      throw new IllegalArgumentException("Invalid email")
    }
  }

  def validatePassword(password: String): Unit = {
    if (password.isEmpty || password.length < 8) {
      throw new IllegalArgumentException("Invalid password")
    }
  }
}

UserRepository: This class handles the persistence of the user. Whether we save to a database, file system, or any other storage medium, this responsibility lies within UserRepository.

class UserRepository {
  def saveUser(username: String, email: String, password: String): Unit = {
    // Simulate saving to a database
    println(s"User registered: $username")
  }
}

NotificationService: This class is responsible for notifying the user. It could be extended to send emails, SMS, or push notifications.

class NotificationService {
  def sendNotification(email: String): Unit = {
    println(s"Notification sent to: $email")
  }
}

The Benefits of SRP

By following the Single Responsibility Principle, our code has become more:

• Maintainable: Changes in one responsibility do not affect others. For example, changing the validation logic won’t impact how users are registered or notified.
• Testable: Each class can be tested independently. Unit tests for UserValidator can focus solely on validation logic without worrying about database interactions or notification logic.
• Scalable: If the application grows and requirements change, new responsibilities can be added without modifying existing classes.

Conclusion

Adhering to the Single Responsibility Principle not only makes our code cleaner and more organized but also prepares it for future growth and modifications. As we’ve seen in this Scala example, breaking down a monolithic class into focused, single-responsibility classes leads to a more modular, maintainable, and testable codebase.

Next time you find yourself writing a class that does too much, remember the SRP and ask yourself, “Can I break this down into smaller, more focused classes?” Embrace the principle, and your code will thank you for it!