Single Responsibility Principle (SRP) | SOLID PRINCIPLES

Single Responsibility Principle (SRP) 

The Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning it should have only one responsibility. 

Let's consider a simple example in C#:

using System;

// Violation of SRP - Single Responsibility Principle

public class Report

{

    public string Title { get; set; }

    public string Content { get; set; }

    public void GenerateReport()

    {

        // Code for generating the report

        Console.WriteLine("Generating report...");

    }

    public void SaveToFile()

    {

        // Code for saving the report to a file

        Console.WriteLine("Saving report to file...");

    }

}

```

In this example, the `Report` class has two responsibilities: generating a report and saving it to a file. This violates the SRP because a class should ideally have only one reason to change.

Now, let's refactor the code to adhere to SRP:

```csharp

using System;

// Following SRP - Single Responsibility Principle

public class Report

{

    public string Title { get; set; }

    public string Content { get; set; }

}

public class ReportGenerator

{

    public void GenerateReport(Report report)

    {

        // Code for generating the report

        Console.WriteLine("Generating report...");

    }

}

public class ReportSaver

{

    public void SaveToFile(Report report)

    {

        // Code for saving the report to a file

        Console.WriteLine("Saving report to file...");

    }

}

Now, we have separated the responsibilities. The `Report` class only contains data related to the report, while the `ReportGenerator` class is responsible for generating reports, and the `ReportSaver` class is responsible for saving reports to files. This adheres to the Single Responsibility Principle, making the code more modular and maintainable. If there's a change in report generation logic, it won't affect the file-saving logic and vice versa.

Real-world example from a web application:

**Violation of SRP:**

Suppose you have a `User` class that represents a user in your system. This class not only handles user data but also contains methods for interacting with the database and sending emails.

public class User

{

    public string UserName { get; set; }

    public string Email { get; set; }

    public void SaveToDatabase()

    {

        // Code for saving user data to the database

    }

    public void SendEmail(string message)

    {

        // Code for sending an email to the user

    }

}

```

In this case, the `User` class violates the Single Responsibility Principle because it has multiple reasons to change – changes in database operations and email functionality.

**Adhering to SRP:**

Now, let's refactor this code to separate concerns:

```csharp

public class User

{

    public string UserName { get; set; }

    public string Email { get; set; }

}

public class UserRepository

{

    public void SaveUser(User user)

    {

        // Code for saving user data to the database

    }

}

public class EmailService

{

    public void SendEmail(User user, string message)

    {

        // Code for sending an email to the user

    }

}

Now, the responsibilities are separated. The `User` class only contains properties related to the user, the `UserRepository` class handles database operations, and the `EmailService` class is responsible for sending emails. This adheres to the Single Responsibility Principle, making each class more focused and easier to maintain. If there's a change in how emails are sent, it won't affect the user data storage, and vice versa.