RakibRahman

Posted on Mar 29

Understanding the Single Responsibility Principle in S.O.L.I.D

#programming #softwaredevelopment #go #beginners

Intro
What is the S.O.L.I.D Principle?
What is SRP?
Real-World Analogy of SRP
Code Example
- Violation of SRP
- Adhering to SRP
What breaks SRP
How to achieve SRP
Benefits of SRP
References
Conclusion

Intro

Writing flexible and scalable code is hard, but the S.O.L.I.D principles help us achieve that. At first glance, S.O.L.I.D may seem daunting, and applying it correctly takes time and practice. However, with proper theoretical knowledge and hands-on experience, mastering these principles becomes achievable.

I’m writing this blog to:

Document my learning journey – so I (and others) can revisit and refresh our understanding.
Improve over time – As I gain more insights, I’ll update and refine my explanations.

This will be a 5-part series, where each blog dives deep into one principle. Let’s begin with the first one: Single Responsibility Principle (SRP)

What is the S.O.L.I.D Principle?

SOLID is an acronym for the first five object-oriented design (OOD) principles, introduced by Robert C. Martin (Uncle Bob) in the early 2000s. These principles help developers create software that is:

Maintainable -> Easy to modify and extend.
Understandable –> Clear and readable structure.
Flexible –> Adapts to changes without breaking.
Scalable –> Reduces complexity as the application grows.

The five principles are:

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

What is SRP?

The Single Responsibility Principle (SRP) states that:

A class or module should have only one reason to change, meaning it should have only one job or responsibility.

In simpler terms:

One class = One primary job or responsibility.
If a class does too much, it becomes harder to maintain.
Changes in one functionality shouldn’t risk breaking unrelated features.

Violating SRP often leads to tight coupling, which makes code hard to test and maintain.

Real-World Analogy of SRP

Let’s try to understand SRP with a real-world scenario. Think of a supershop where:

The cashier only deals with cash (doesn’t help customers find products).
The salesman only helps customers locate desired products (doesn’t manage cash).
The cleaner only cleans (doesn’t assist with product searches or cash handling).

The supershop works efficiently because each expert focuses on their responsiblity. Changes to one role do not disrupt others.

Code Should Work the Same Way!
Just as you wouldn't expect a cleaner to handle billing, a class or module shouldn't mix unrelated responsibilities.

Code Example

Enough theoretical knowledge. Let's see SRP in action. I'll use Go(Golang) to demonstrate the SRP, but the following example should also apply to other languages.

Violation of SRP

Let’s look at a common scenario where SRP is violated. In this example, the User struct handles both saving data to the database and sending emails.

type User struct {
    name  string
    email string
}

// Violation of SRP. It handles both database operations and email sending.
func (u *User) Save() error {
    // Logic to save user to the database
    fmt.Printf("Saving user %s to database\n", u.name)

    // Logic to send email
    u.SendEmail(u.email, "Welcome to our community")
    return nil
}

func (u *User) SendEmail(email, message string) {
    // Email sending logic
    fmt.Println(message, email)
}

func main() {
    user := User{name: "Rakib", email: "rakib@gmail.com"}
    user.Save()
}

The Save method handles both database and email operations, which violates SRP.
Additionally, we can’t reuse database/email-related logic because it’s tightly coupled to the Save method.

Adhering to SRP

Now, let’s refactor the code to adhere to SRP. We’ll separate the responsibilities into dedicated methods.

type User struct {
    name  string
    email string
}

// DatabaseService handles database operations - single responsibility
type DatabaseService struct{}

func (db *DatabaseService) SaveUser(user *User) {
    // Logic to save user to the database
    fmt.Println("Saving user to database", user.name)
}

// EmailService handles email-related operations - single responsibility
type EmailService struct{}

func (es *EmailService) SendEmail(user *User, message string) {
    // Logic to send an email
    fmt.Println(message, user.email)
}

func main() {
    user := User{name: "Rakib", email: "rakib@gmail.com"}

    dbService := &DatabaseService{}
    emailService := &EmailService{}

    dbService.SaveUser(&user)
    emailService.SendEmail(&user, "Welcome to our community")
}

Now, we’ve assigned each responsibility to a separate module:
- DatabaseService handles database operations.
- EmailService handles email-related operations.
The SaveUser and SendEmail methods are not tightly coupled, can be reused, and changing one’s logic does not disrupt the other.

What breaks SRP

Here are some common scenarios where SRP is broken:

1. Not adhering to DRY principle.

Duplicate functionality in your code violates SRP. If you copy-paste the same logic into multiple places, it often indicates scattered responsibilities and a lack of a single source of truth.

   // Duplicate validation logic in two places  
func CreateUser(name string, email string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    // ... rest of the function  
}

func UpdateUser(name string, email string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    // ... rest of the function  
}

In the above example, the CreateUser and UpdateUser methods use the same logic for validating the name. If we need to update the logic, we have to do it manually in each method.

2. Missing KISS principle.

When a class tries to do too much, it becomes overly complex and difficult to understand. The level of abstraction is missing.

  type Report struct {}

func (r *Report) Generate() string { /* ... */ }
func (r *Report) SaveToFile() error { /* ... */ }
func (r *Report) SendEmail() error { /* ... */ }

Here, the Report struct handles generating reports, saving them to files, and sending emails—all in one place.

3. Tight Coupling

When a class is tightly coupled with other classes or modules, it becomes harder to modify one without affecting others. This coupling often arises when a class takes on responsibilities that don't belong to it.

type Order struct {
    DB *sql.DB
}

func (o *Order) Process() error {
    // Business logic + direct database access  
    _, err := o.DB.Exec("INSERT INTO orders...")
    return err
}

The Order struct is directly responsible for both business logic and database operations, making it tightly coupled with the database.

How to achieve SRP

To adhere to the Single Responsibility Principle, address the issues outlined above with these strategies:

1. Adhere to the DRY Principle

Centralize shared functionality into a single module or function. For example, extract the validation logic into a dedicated function to avoid duplication.

func ValidateName(name string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    return nil
}

func CreateUser(name string, email string) error {
    if err := ValidateName(name); err != nil {
        return err
    }
    // ... rest of the function  
}

func UpdateUser(name string, email string) error {
    if err := ValidateName(name); err != nil {
        return err
    }
    // ... rest of the function  
}

2. Follow the KISS Principle

Keep classes simple and focused. Each class should have one clear responsibility. Split the Report struct into smaller, focused structs.

type ReportGenerator struct{}

func (r *ReportGenerator) Generate() string {
    // Logic for generating report
    return "Generated Report"
}

type FileSaver struct{}

func (f *FileSaver) SaveToFile(content string) error {
    // Logic for saving to file
    return nil
}

type EmailSender struct{}

func (e *EmailSender) SendEmail(content string) error {
    // Logic for sending email
    return nil
}

Each struct now has a single responsibility: generating reports, saving files, or sending emails.

3. Avoid Tight Coupling

Use composition to delegate responsibilities to other classes. For instance, separate the business logic from database operations by injecting a repository or service.

  type OrderRepository struct {
    DB *sql.DB
}

func (r *OrderRepository) Save(orderData map[string]interface{}) error {
    // Database-specific logic
    _, err := r.DB.Exec("INSERT INTO orders...", orderData)
    return err
}

type Order struct {
    Repository *OrderRepository
}

func (o *Order) Process(orderData map[string]interface{}) error {
    // Business logic only
    return o.Repository.Save(orderData)
}

Here, the Order struct delegates database operations to the OrderRepository, reducing coupling and adhering to SRP.

Benefits of SRP

Reusability -> The DatabaseService and EmailService can be reused across different parts of the application, reducing duplication.
Easier debugging -> Responsibilities are isolated, so it’s easier to pinpoint issues.
Simpler testing -> Each class or module has a clear purpose and can be tested independently. It allows for unit testing without mocking unrelated logic.
Better organization -> The code is modular, providing greater readability.
Maintainability -> Changing one module does not cause unintended side effects in other modules. For example, if the email-sending logic changes (e.g., switching from SMTP to an external service), only the EmailService needs modification, leaving the DatabaseService unaffected.
Abstraction -> SRP often leads to better abstraction, which is a key concept in good software design.

References

Conclusion

Simply put, implementing SRP greatly improves code quality. It makes the code easier to maintain, test, and scale. Always try to implement SRP in your projects to improve code quality. Stay tuned for the next blog in the series, which will cover the Open/Closed Principle (OCP).

That’s all for today! Thank you for reading, and don’t forget to connect with me on LinkedIn to get updates.

If you have any questions or feedback, please leave a comment below!