SOLID - Single Responsibility Principle With C#

Mark defines registration and mail sending functionality in the EmployeeService class. This class holds two methods, one for registration of employee while another method is for sending mail to the employee. Each method defines as per functionality so that these don’t violate SRP. The following code snippet is for the same.

using MailKit.Net.Smtp;  
using MailKit.Security;  
using MimeKit;  
using System.Threading.Tasks;  
  
namespace SRPApp  
{  
    public class EmployeeService  
    {  
        public async Task EmployeeRegistration(Employee employee)  
        {  
            StaticData.Employees.Add(employee);  
            await SendEmailAsync(employee.Email, "Registration", "Congratulation ! Your are successfully registered.");  
        }  
        private async Task SendEmailAsync(string email, string subject, string message)  
        {  
            var emailMessage = new MimeMessage();  
  
            emailMessage.From.Add(new MailboxAddress("Mark Adam", "[email protected]"));  
            emailMessage.To.Add(new MailboxAddress(string.Empty, email));  
            emailMessage.Subject = subject;  
            emailMessage.Body = new TextPart("plain") { Text = message };  
  
            using (SmtpClient smtpClient = new SmtpClient())  
            {  
                smtpClient.LocalDomain = "sample.com";  
                await smtpClient.ConnectAsync("smtp.relay.uri", 25, SecureSocketOptions.None).ConfigureAwait(false);  
                await smtpClient.SendAsync(emailMessage).ConfigureAwait(false);  
                await smtpClient.DisconnectAsync(true).ConfigureAwait(false);  
            }  
        }  
    }  
}

The preceding code is developed in .NET Core, that’s why .NET Core MailKit Nuget package is used to send an email. This email send code is used for demonstration purpose. It will be worked with valid credentials and domain.

As Mark uses same console application for UI interaction so he updates it as per following code snippet.

using System;  
  
namespace SRPApp  
{  
    class Program  
    {  
        static void Main(string[] args)  
        {  
            Employee employee = new Employee  
            {  
                FirstName = "John",  
                LastName = "Deo",  
                Email = "[email protected]"  
            };  
            EmployeeService employeeService = new EmployeeService();  
            employeeService.EmployeeRegistration(employee).Wait();  
            Console.ReadKey();  
        }  
    }  
} 

Demonstration

Since the module was ready, Mark demonstrated the same to Bob, and Bob again appreciates the architecture. All things are looking good and working as per expectation such as,

1. He defines separate classes for both employee data and functionality.
2. The methods are separated based on functionalities.
3. He defines a separate class for employee storage which is static.

Problem with Preceding Design

The preceding code is working perfectly but it is still violating the Single Responsibility Principle. The EmployeeService class holds two methods ,one for registration of employee while another method is for sending mail to the employee. The email sending functionality is not related to the employee entity directly. The email send and employee registration are totally different functionalities. If we change email sending process such as change provider, add attachment and use SSL etc then EmplyeeService class should not be changed but it isn't possible in preceding code.

Bob explained to Mark that a class should have only reason to change and have a single responsibility. The EmployeeService class has two responsibilities so it violates the SRP principle. It doesn’t mean that a class can’t have more than one method. A class can have multiple methods but these are related to one entity of the application. In other words, EmployeeService class can have multiple methods related to the Employee entity such as registration, update and delete etc.. Mark understood that what he did wrong here and how violates the SRP principle. Now, he knows about the Single Responsibility Principle. He starts to update in existing code for SRP.

Final Development

Mark has an understanding that a class should have a single responsibility. He knows very well where he needs to change in the existing code. But he needs to implement these changes without violating SRP.

Mark knows that he needn’t build the entire application. He needs to change in the email sending functionality. He needs to make it independently so that it could be used as another place in the application. So, there are two changes in the application. Email sending code should be removed from EmployeeService class. He needs to define a new class for email sending functionality.

He defines a new class named EmailService to send email as per following code snippet.

using MailKit.Net.Smtp;  
using MailKit.Security;  
using MimeKit;  
using System.Threading.Tasks;  
  
namespace SRPApp  
{  
  public  class EmailService  
    {  
        public async Task SendEmailAsync(string email, string subject, string message)  
        {  
            var emailMessage = new MimeMessage();  
  
            emailMessage.From.Add(new MailboxAddress("Mark Adam", "[email protected]"));  
            emailMessage.To.Add(new MailboxAddress(string.Empty, email));  
            emailMessage.Subject = subject;  
            emailMessage.Body = new TextPart("plain") { Text = message };  
  
            using (SmtpClient smtpClient = new SmtpClient())  
            {  
                smtpClient.LocalDomain = "paathshaala.com";  
                await smtpClient.ConnectAsync("smtp.relay.uri", 25, SecureSocketOptions.None).ConfigureAwait(false);  
                await smtpClient.SendAsync(emailMessage).ConfigureAwait(false);  
                await smtpClient.DisconnectAsync(true).ConfigureAwait(false);  
            }  
        }  
    }  
}

Mark uses the preceding code to send an email and call it in EmployeeService as per the following code snippet.

using System.Threading.Tasks;  
  
namespace SRPApp  
{  
    public class EmployeeService  
    {  
        public async Task EmployeeRegistration(Employee employee)  
        {  
            StaticData.Employees.Add(employee);  
            EmailService emailService = new EmailService();  
            await emailService.SendEmailAsync(employee.Email, "Registration", "Congratulation ! Your are successfully registered.");  
        }         
    }  
}

There is no change in the rest of the application.

Demonstration

Mark demonstrated the same to Bob. Now, it follows the Single Responsibility Principle. As he defined classes based on responsibilities and method based on individual functionality such

1. He defines separate classes for employee data, functionality, email sending, UI interaction and data storage.
2. Each class has a single responsibility and there is only one reason to change a class and method.

Now, Mark has implemented the Single Responsibility Principle in the application using C#. Bob seems happy because all his requirements seem satisfied and Mark is also happy because now he has become champ in the Single Responsibility Principle.

Conclusion

The SRP principle states that if we have two reasons to change for a class, we have to split the functionality into two classes. Each class will handle only one responsibility and in the future, if we need to make one more change we are going to make it in the new class which handles it.

If we put more than one functionality in one class then it introduces coupling between two functionalities. So, if we change one functionality there is a chance we broke coupled functionality, which requires another round of testing to avoid any bug in the production environment.

It reduces bug fixes and testing time once an application goes into the maintenance phase. It follows the DRY principle.