SOLID Principles - Single Responsibility Principle

The worst time to learn anything new related to your job is during an interview. I was drilled on SOLID principles some years back. It felt as if I am being interviewed to teach Chemistry. There is no way, I can disclose the year it happened as my manager might be reading this article and I love my current salary. Oh sorry, I meant my job.

The SOLID principle is a subset of many principles promoted by American software engineer and instructor Robert C Martin informally known as “Uncle Rob”. In this article, I would be talking about one of the SOLID principles i.e (S)ingle Responsibility Principle (AKA SRP).

Another article on Single Responsibility. Why?????

Writing is the best way to improve knowledge. Over the past few days, I have read extensively on this topic. Reading brought a fresh perspective. It helped me in identifying code snippets violating SRP in my current and previous projects. Hopefully, this article will be helpful to people who want to improve there coding style.

What is “Single Responsibility Principle”?

Each software module should have one and one responsibility and hence will have only one reason to change

Single responsibility principle provides two values:

1. Primary Value: Ease of Change
2. Secondary Value: Meeting user’s needs

Let’s look into an example to see this into action.

Imagine a Shoe Warehouse in Sydney and the manager (Joe) wants the IT team to create a report on the stock present in the warehouse.

Class ReportGenerator

The above class is self-sufficient to create reports accessible via 4 different ways:

1. Print
2. Email
3. Online
4. Export

Does this class violate the Single Responsibility Principle? It all depends on the users of this application. Let’s look at a change request:

1. Joe wants some additional fields to be added to the email report for the Sydney Warehouse.
2. Andrew, a senior manager wants to use this application to view online reports for all the warehouses in Australia.

IT team allocates two different developers to work on the requirement for Joe and Andrew respectively. The problem is that both the developers will have to work on the same class.

While the developers were struggling to synchronize there work, a new requirement came from senior management.

• The senior management wants to send an email report to external retail outlets so that they can be informed about the inventory stock before placing their orders. Moreover, the logic to generate this report is complex and different from the report Joe is expecting.

After carefully reviewing the class, the IT development team came up with the following conclusion:

1. The current code is violating SRP. Any change in logic will impact Joe, Andrew, and external Retail outlets (Tightly Coupled).
2. ReportGenerator class is handling 4 different responsibilities, hence they should be divided into 4 different classes.

Summary

1. The primary value SRP brings is the ease of change and the best way to calculate responsibility is to identify various sources responsible for a change.
2. The changes are driven by users, hence identification of users is very critical to implement as many features as possible (i.e SRP’s second value)

References

1. https://blog.devgenius.io/solid-take-responsibility-c5404bf2d4c8?sk=29b469d3fe353abec3e3352f9dc69559
2. https://medium.com/@severinperez/writing-flexible-code-with-the-single-responsibility-principle-b71c4f3f883f
3. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
4. https://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
5. https://en.wikipedia.org/wiki/SOLID
6. https://en.wikipedia.org/wiki/Robert_C._Martin
7. https://en.wikipedia.org/wiki/Single_responsibility_principle

Regards Tarun