SOLID Principles In C# - Single Responsibility Principle

Introduction

 
C# is an object-oriented programming language. These days whenever you talk about object-oriented programming you hear the acronym, SOLID. These are five design principles introduced by Michael Feathers to make our object-oriented applications easy to understand, maintain and expand as future requirements change. Today, we will look at the first principle with an example and in the following articles we will cover the remaining principles with examples of each.
 

The SOLID principles

 
There are five principles to follow to ensure our application meets the SOLID requirements. These are as below,
  1. Single Responsibility Principle (SRP)
  2. Open Closed Principle (OCP)
  3. Liskov Substitution Principle (LSP)
  4. Interface Segregation Principle (ISP)
  5. Dependency Inversion Principle (DIP)

The Single Responsibility Principle (SRP)

 
The Single Responsibility Principle (SRP) states that a class should have one single piece of responsibility in the application. It should have only one reason to change and that is if the single piece of responsibility needs a change. This will ensure the class and ultimately the whole application is very robust and easy to maintain and expand, if required. Let us look at this with an example,
 
Let us create a new .NET Core 3.1 console application in Visual Studio 2019 Community Edition as below,
 
SOLID Principles In C# - Single Responsibility Principle
 
SOLID Principles In C# - Single Responsibility Principle
 
Inside this project, I have created a new class file “SingleResponsibilityPrinciple”. In this file, I create the following “Student” class.
  1. // Not following the Single Responsibility Principle  
  2.   
  3.     public class Student  
  4.     {  
  5.         public string ID { get; set; }  
  6.         public string Name { get; set; }  
  7.         public string Email { get; set; }  
  8.         public float PaperAMarks { get; set; }  
  9.         public float PaperBMarks { get; set; }  
  10.         public float PaperCMarks { get; set; }  
  11.         public float BasicTution { get; set; }  
  12.         public float OtherFees { get; set; }  
  13.   
  14.         public float CalculateMarksAverage()  
  15.         {  
  16.             return (PaperAMarks + PaperBMarks + PaperCMarks) / 3;  
  17.         }  
  18.   
  19.         public float CalculateFees()  
  20.         {  
  21.             return BasicTution + OtherFees;  
  22.         }  
  23.     }  
This class does not follow the “Single Responsibility Pattern” as we are adding the marks calculation and fees calculation into the main student class. Hence, if there is any need to change anything in the fees calculation, we would need to change the main student class and then unit test all the three components including the main student class, the marks calculator class and the fees calculator class. Hence, we have not given a single responsibility to the student class.
 
We can fix this as below,
  1. // Following the Single Responsibility Principle  
  2.       
  3.     public interface IStudentMarksCalculator  
  4.     {  
  5.         float PaperAMarks { get; set; }  
  6.         float PaperBMarks { get; set; }  
  7.         float PaperCMarks { get; set; }  
  8.         float CalculateMarksAverage();  
  9.     }  
  10.   
  11.     public class StudentMarksCalculator : IStudentMarksCalculator  
  12.     {  
  13.         public float PaperAMarks { get; set; }  
  14.         public float PaperBMarks { get; set; }  
  15.         public float PaperCMarks { get; set; }  
  16.         public float CalculateMarksAverage()  
  17.         {  
  18.             return (PaperAMarks + PaperBMarks + PaperCMarks) / 3;  
  19.         }  
  20.     }  
  21.   
  22.     public interface IStudentFeesCalculator  
  23.     {  
  24.         float BasicTution { get; set; }  
  25.         float OtherFees { get; set; }  
  26.         float CalculateFees();  
  27.     }  
  28.   
  29.     public class StudentFeesCalculator: IStudentFeesCalculator  
  30.     {  
  31.         public float BasicTution { get; set; }  
  32.         public float OtherFees { get; set; }  
  33.         public float CalculateFees()  
  34.         {  
  35.             return BasicTution + OtherFees;   
  36.         }  
  37.     }  
  38.   
  39.     public class StudentFixed  
  40.     {  
  41.         public string ID { get; set; }  
  42.         public string Name { get; set; }  
  43.         public string Email { get; set; }  
  44.   
  45.         private readonly IStudentMarksCalculator _studentMarksCalculator;  
  46.         private readonly IStudentFeesCalculator _studentFeesCalculator;  
  47.   
  48.         public StudentFixed(IStudentMarksCalculator studentMarksCalculator, IStudentFeesCalculator studentFeesCalculator)  
  49.         {  
  50.             _studentMarksCalculator = studentMarksCalculator;  
  51.             _studentFeesCalculator = studentFeesCalculator;  
  52.         }  
  53.   
  54.         public float GetMarks(float A, float B, float C)  
  55.         {  
  56.             _studentMarksCalculator.PaperAMarks = A;  
  57.             _studentMarksCalculator.PaperBMarks = B;  
  58.             _studentMarksCalculator.PaperCMarks = C;  
  59.             return _studentMarksCalculator.CalculateMarksAverage();  
  60.         }  
  61.   
  62.         public float GetTution(float Basic, float Others)  
  63.         {  
  64.             _studentFeesCalculator.BasicTution = Basic;  
  65.             _studentFeesCalculator.OtherFees = Others;  
  66.             return _studentFeesCalculator.CalculateFees();  
  67.         }  
  68.   
  69.     }  
In the above code, we see that we have created two classes. One for calculating the fees of the student and the other to calculate the marks of the student. Both are injected into the main student class using dependency injection, which we will look into when we discuss the last SOLID principle called dependency inversion. Hence, any changes required in the fees calculation or marks calculation classes can be done independently and would not impact the main student class if the interfaces of these classes do not change.
 
If we run both the implementations above, we get the same results, but one has applied the SRP correctly and the other has not.
  1. //Calling class not following Single Responsibility Principle  
  2.   
  3.             var student = new Student();  
  4.   
  5.             student.PaperAMarks = 75.5F;  
  6.             student.PaperBMarks = 81F;  
  7.             student.PaperCMarks = 79.5F;  
  8.   
  9.             Console.WriteLine($"The student's average marks are {student.CalculateMarksAverage()}");  
  10.   
  11.             student.BasicTution = 1500F;  
  12.             student.OtherFees = 255.75F;  
  13.   
  14.             Console.WriteLine($"The student's Fees is {student.CalculateFees()}");  
  15.   
  16.             //Calling class following Single Responsibility Principle  
  17.   
  18.             var studentFixed = new StudentFixed(new StudentMarksCalculator(), new StudentFeesCalculator());  
  19.   
  20.             Console.WriteLine($"The student's average marks are {studentFixed.GetMarks(75.5F, 81F, 79.5F)}");  
  21.             Console.WriteLine($"The student's Fees is {studentFixed.GetTution(1500F, 255.75F)}");  
SOLID Principles In C# - Single Responsibility Principle

Summary

 
In this article, we have looked at implementing the Single Responsibility Pattern (SRP) in a practical example. I would recommend you look though your existing classes and identify places where you have violated this principle and then think of ways to fix it. This will help to get you thinking in terms of applying this principle and help you to apply it to your code in the future as well. In my next article, we will look at the Open Closed Principle.

Recommended Ebook

Diving Into Microsoft .NET Entity Framework

Download Now!
Similar Articles