The next few chapters discuss how SOLID principles are relevant at architecture level and discusses them briefly starting with SRP. 

S in SOLID principles is called Single Responsibility Principle (SRP).

It is quite normal to assume that SRP means every module should do just one thing because of the inappropriate name. Before reading this chapter, even I had the same misconception. Let’s clear this up in this post.

The most accepted definition of SRP is – 

A module should have one, and only one, reason to change. 

A software system is changed to satisfy stakeholders and users. So the users and stakeholders are the “reason to change”. The users and stakeholders can be grouped into one actor that require the software to change. So the author gives this as final definition of SRP –

A module should be responsible to one and only one actor .

Now, let’s look at the ways in which this principle is violated to better understand it. 

1. Accidental Duplication

Let’s say we have class A that has three methods method1, method2, and method3. Class B’s method depends on method1, Class C’s method depends on method2 and Class D’s method depends on method3.

We can clearly see that Class A is violating SRP as we have three different actors depending on it’s method. Say, method1 and method2 depend on some logic in methodE of Class E. If methodB requires a changes in methodE’s logic, goes ahead and makes the change, tests and deploys it. Later methodC finds out the issue it is facing is because of change in methodE. All this can be avoided if we separate code from a class that different actors depend on.  

2. Merges

We all see this fairly often, two developers are working on same class and there is merge conflict when they push their code which needs to be resolved. 

Let’s say developers from team B and team C are working on Class A, they make some changes which is now resulting in conflict. Now both the teams have to come together solve the conflict before pushing the changes. 

All this can be avoided if we separate code that supports different actors. 

Solutions

One of the solutions is to have each function is separate functions from data, where in each class depends on the data which is simple data structure without functions. 

For example, say we have Employee class with three functions calculatePay, reportHours and saveEmployee which are responsible to three different actors respectively. Instead, we can separate out the three functions into three classes where each class will be responsible to one actor. So, we can have PayCalculator, HoursReporter, and EmployeeSaver each having their own functions that depend on EmployeeData. It leads to problem of having three different classes and separate ways to initialize them, for which facade pattern can be used. Now each class follows SRP, as each class is responsible to only one actor. 

Thanks for stopping by! I hope this gives a good preview into SRP. Eager to hear your thoughts and chat, please leave comments below and we can discuss.