Academic Corporate Fusion

Mastering SOLID Principles: Building Robust and Scalable Software

Adhere to the SOLID principles for object-oriented design:

  1. Single Responsibility Principle (SRP): Each class/module should have one responsibility.
  2. Open/Closed Principle (OCP): Modules should be open for extension but closed for modification.
  3. Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types.
  4. Interface Segregation Principle (ISP): Prefer smaller, specific interfaces over large, general ones.
  5. Dependency Inversion Principle (DIP): Depend on abstractions, not concrete implementations.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) states that a class or module should have only one reason to change, meaning it should focus on a single responsibility or functionality. This principle is one of the five SOLID principles of object-oriented programming and is critical for creating maintainable and modular software.

Why Follow SRP?

  1. Clarity: A class focused on a single responsibility is easier to understand.
  2. Maintainability: Changes to a class are confined to its specific responsibility, reducing the risk of side effects.
  3. Reusability: Classes with a single responsibility are easier to reuse in different parts of the application.
  4. Testability: Focused classes are simpler to test.

Example 1: Violation of SRP

Problem:

A class handles multiple responsibilities: storing user data and sending emails

public class UserManager {

    // Stores user data
    public void saveUser(User user) {
        // Code to save user in the database
        System.out.println("User saved: " + user.getName());
    }

    // Sends a welcome email
    public void sendWelcomeEmail(User user) {
        // Code to send email
        System.out.println("Welcome email sent to: " + user.getEmail());
    }
}

Issues:

  • Multiple Responsibilities:
    1. Storing user data (Database-related responsibility).
    2. Sending welcome emails (Email-related responsibility).
  • Tight Coupling: Both functionalities are coupled within a single class.
  • Difficult to Modify: If email logic changes (e.g., to use a new email provider), the UserManager class needs to change, potentially affecting unrelated functionalities.

Applying SRP

// Handles database-related operations
public class UserRepository {
    public void saveUser(User user) {
        // Code to save user in the database
        System.out.println("User saved: " + user.getName());
    }
}

// Handles email-related operations
public class EmailService {
    public void sendWelcomeEmail(User user) {
        // Code to send email
        System.out.println("Welcome email sent to: " + user.getEmail());
    }
}

// Coordinates operations
public class UserManager {
    private UserRepository userRepository;
    private EmailService emailService;

    public UserManager(UserRepository userRepository, EmailService emailService) {
        this.userRepository = userRepository;
        this.emailService = emailService;
    }

    public void registerUser(User user) {
        userRepository.saveUser(user);
        emailService.sendWelcomeEmail(user);
    }
}

Benefits:

  1. Single Responsibility:
    • UserRepository handles database interactions.
    • EmailService handles email logic.
    • UserManager coordinates these two services.
  2. Modular Design:
    • You can modify the email logic or database logic independently.
  3. Reusability:
    • Other parts of the application can reuse EmailService or UserRepository

Comments (645)

Leave A Comment

Call Now Button