The Single Responsibility Principle (SRP)

How many times you have been tasked to change a class because some functionality is out of date and needs some upgrade? How many times a simple change turns out to be a complicated egg hunt of how a class is working? How many times a small business decision, such as changing a text in the application requires to change a bunch of lines in the code? Have you ever feel this kind of pain. It so, then the Single Responsibility Principle comes to your rescue.

Robert C. Martin, also know as Uncle Bob, defined the Single Responsibility Principle as follows: a class can only have one, and only one, reason to change.  But, how we can explain this principle? If we see our nature world, we know that the sun has a unique job. It provides the heat necessary to sustain life in earth. If the sun ends providing heat, then life will not be possible on earth. So the sun has only one thing to do, one and a single responsibility.

The same happens when we are designing our software applications. We design a project with multiple classes. Each class must fulfill a unique purpose. This unique purpose will serves us in the long run, since it will allow us to create a very reusable system.  For example, we can create a system that reads some files, encrypt them and then saves the encrypted data to a database.  We can create a class like this:

public class FileHander
{
		public void ReadFiles(string path){}
		public void EncryptData(){}
		public void SaveData(){}
}

We will have a serious problem of reusability, since we have now three unique operations in one class. We can ask ourselves: what happens if we decide to reuse the EncryptData method to encrypt not just file data but other kind of data? What if we need to save the data in a new database or other kind of storage? If we need to make any change to any of the three methods, we will impact the rest of the class. This will mean extra time of testing.We can think, I will not need to test the encryption method since I am only changing the ReadFiles method. But, If you are lucky enough to not use class level variables to handle the data between each method, you are in a good position. But as developers, we know we usually don’t have that luxury. And many times, the class we are dealing was not written by us.

The best way to implement the Single Responsibility Principle in the above class is to separate them into three different classes; one that handles the file reading, another that handles the encryption and another that handles the data storage. Example:

public class FileReader
{
		public string[] Read(string path){}
}

public class Encryption
{
		public string[] Encrypt(string[] data){}
}

public class Data
{
		public void Save(string[] data){}
}

public class FileHandler
{
		public void ProcessFile(string path){
		{
			var fileReader = new FileReader();
			var rawData = fileReader.Read(path);
			
			var encryption = new Encryption();
			var encryptedData = encryption.Encrypt(rawData);
			
			var data = new Data();
			data.Save(encryptedData);
		}
}

Ok, ok. You can tell me that this is more work, more typing. But believe me, this will help you later. When we separate each method in a single class, with only one responsibility, you can see now the advantages. You need to change the Save method to use an Oracle database instead of a SQL Server database, you only change that method. The Encryption class or the FileReader class does not need to know what kind of database you are using. The same happens with the Encryption class, you can use SHA, PGP or other kind of encryption, and the Data class does not need to know. It only waits for some data already encrypted.

As you can see, the Single Responsibility Principle allows you to simplify your application design into a more manageable classes. It will allow you compartmentalized your application in unique functionalities. It will help you in the future if you need to make important changes to your code.