Mastering SOLID Principles: Building Robust and Scalable Software

December 31, 2024
By admin
solid principles

Mastering SOLID Principles: Building Robust and Scalable Software

Adhere to the SOLID principles for object-oriented design:

Single Responsibility Principle (SRP): Each class/module should have one responsibility.
Open/Closed Principle (OCP): Modules should be open for extension but closed for modification.
Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types.
Interface Segregation Principle (ISP): Prefer smaller, specific interfaces over large, general ones.
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?

Clarity: A class focused on a single responsibility is easier to understand.
Maintainability: Changes to a class are confined to its specific responsibility, reducing the risk of side effects.
Reusability: Classes with a single responsibility are easier to reuse in different parts of the application.
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:

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