SRP: Single Responsibility Principle

One class should only have one responsibility

Published in

Swift India

4 min readDec 27, 2018

The Single Responsibility Principle (SRP) states that each software module or class should have one and only one reason to change.

None but Buddha himself must take the responsibility of giving out occult secrets . . .

Gather together the things that change for the same reasons. Separate those things that change for different reasons.
— Bob Martin

What’s the issue in sharing responsibility?

Difficulty in understanding and therefore, difficulty in maintenance.
Difficulty of reuse. With responsibilities connected closely in the same class, it can be difficult to change one of these responsibilities without compromising others (rigidity) and may end up breaking other parts of the software (fragility).
High coupling, i.e., the class has an excessive number of dependencies and therefore is more subject to changes due to changes in other classes (again the fragility).

Credit: https://giphy.com

What do I mean by Single?

Single denotes some work in isolation. If your method, class component does one thing it does not do two things. There are various ways to identify what is single and what is not. In general, you need to recognize when your code tends to know a little bit more than already does. With this, function or class name should reflect the implemented functionality.

Let’s take an example: We have to calculate sum of square of digits of 25

This function does more than single work and function name also doesn’t reflect functionality completely which is giving sign of bad design.

Let’s refactor this code:

What do I mean by Responsibility?

Responsibility is the work or job that each part of your system, the methods, the classes and the modules are assigned to do. Too much responsibility leads to coupling while cohesion refers to how closely the contents of a class.

Components with low cohesion does tasks that are not related to their responsibilities.

What defines a reason to change?

There are three specific causes of change: adding new features, correcting faults and restructuring code to accommodate future changes.

Perhaps the code is not responsible for bug fixes or refactoring. Those things are the responsibility of the programmer, not of the program. But if that is the case, what is the program responsible for? Or, perhaps a better question is: who is the program responsible to? Better yet: who must the design of the program respond to?

We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.

Reasons for change are people. It is people who request changes. And you don’t want to confuse those people by mixing together the code that many different people care about for different reasons.

Let’s take the example of UIViewController. We can break SRP easily in iOS as we have our god object UIViewController. It allows us to do everything there itself, without any restriction which provokes bad code.

A view controller can be a data source or delegate of your table view or collection view,
It can make web requests
It can have business logic
It can have formatting and validation logic

If there is a change in business logic, we need to touch view controller, if there is a change in validation logic, again we need to touch view controller which can make it fragile and it will be difficult to write tests for this kind of code. Changes in web request can be requested from the back-end team while changes in business logic can be requested from the business side. In any case, changes requested from one person shouldn’t modify code responsible for other people.

What should be separated?

Let’s think about some responsibilities that may need to be separated:

HTTP API call — If there is a need to modify header or base URL, it could be modified only into HTTPClient. There is no need to do changes in other files for this requirement.
ViewState creation — It should be a factory or converter responsibility to create view state.
Validation — All validation logic should be encapsulated into separate Validation class so in future only one person is responsible for modifying validation logic or for adding new behavior.
Persistence
Notification
Error Handling
Logging
Formatting
Parsing
Mapping
Navigation
Business logic
Creation of View