Adeogo Favour's Blog

Single Responsibility Principle

An in-depth Analysis

Adeogo Favour's photo
Adeogo Favour
·

3 min read

Table of contents

Overview

Welcome to my first SOLID Principle Series (SPS). I did a bit of writing on that in the Last Post. (Tip: You should check out some stuff I said there, maybe prove me wrong). We’ll be talking about the Single Responsibility Principle (SRP). It just states that each software module or class should have only one reason to change, Also it explains that classes or methods should have only one responsibility.

Of all principles, I found this the most interesting to dig into, not just because it was the first letter haha but because it’s the basic concept of Object-Oriented Programming(OOP). Basically, people versed in OOP know it's generically likened to building a house with all the components or models put together. In each component are functions.

Now we have an Employee class that should perform three functions, Below is what SRP talks about pictorally.

Employee class

  1. Now I have Ed here; he gets hired by Laura to build an Employee Management System (EMS). He builds a Demo EMS but his deliveries at the first stage of testing aren’t as impressive to Laura, Why wasn’t it Impressive?

    Ed defined a class named Employee Service. It holds both employee data and registration operations in the code snippet.

      public class Employees
     {
         public int Id { get; set; }
         public string Name { get; set; }
         public int EmployeeId { get; set; }
         public string Department { get; set; }
     }
  public void EmployeeRegistration(EmployeeService employee)
         {
             StaticData.Employees.Add(employee);
         }

    Ed also used a local storage to store data rather than a database so he defines another class named ListData. It has a property to store employee lists. This is explained in the code snippet.

      public class ListData
     {
         public static List<EmployeeService> Employees { get; set; } = new                List<EmployeeService>();
     }

    To keep it simple, Ed chooses a console application for UI interaction. It could be a web or Windows application.

      class Program
     {
         static void Main(string[] args)
         {
             Employees employee = new Employees
             {
                 FirstName = "John",
                 LastName = "Doe"
             };
             employees.EmployeeRegistration(employees);
             Console.ReadKey();
         }

    Laura appreciates this but has some other things to add to this Application, like a Mail Service to send emails to users after they Register.

    Problem with Design

    The requirement has changed. One is changing the data; whereas another one might be asked of Ed eg storing employees' names. One of the codes impacts the functionality and the other changes the data. Hence, we have two different reasons to change a single class which violates the Single Responsibility Principle.

    Ed realizes that he should develop code in this way so that data and functionality can be separated.

    How can this code be made better?

    I'll listen to that in the comment section

    Conclusion

    The SRP has many benefits to improve code complexity and maintenance. Some are,

    1. In Maintenance, whenever a functionality changes, we don’t have to change the entire model.

    2. It Reduces the complexities that come with coding. Since a method holds one responsibility, it's less complex that way.

    3. It reduces dependency errors since a method’s code isn’t dependent on other methods.

    4. It’s just the right thing to do haha. As a human it’s almost impossible to multitask, a computer can do that but doesn’t one task at a time go well?

See you next time!

C#