If you are a visual learner, this article is also available as a video here:

The single responsibility principle states that a class or a method should:

1. be responsible for one and only one thing and
2. should have only one reason to change

Let’s look at what it means using an example.

Considering you’re making a driving simulator, you’d have a class to represent a car that looks like this.

A car is responsible for moving and steering, so this class follows the single responsibility principle. But then you decide to add a car-washing feature to your game, and how about a repair feature? We can simply add these functions to the car class.

But is washing and repairing itself the responsibility of the car? No, a mechanic should be responsible for repairs and a car wash for the washing. Of course, implementing it like this would still work, but the car class now has more reasons to change. We can change the car class in cases where we want to update its own driving and steering logic but also how a mechanic repairs it or how a car wash washes it.

This also muddies up the understanding in a collaborative environment. Suppose you made a change to the repair logic and pushed it to a remote repository. For someone else looking at the changelog, it is not immediately clear if the car’s functionality is changed or the repairs or the car wash.

A better way would be to extract the repair and car wash functionalities into mechanic and car wash classes respectively.

Now, responsibilities are clearly defined. A car is responsible for driving and steering, a mechanic for repairing, and a car wash for washing the car.

This also promotes maintainability. Suppose we added another Vehicle, a Truck. We wanted to have some repair logic that applies to all vehicles but some custom repair logic for each different type of vehicle as well. We could have an arrangement like this where we have a Vehicle class with the drive and steer logic and the common repair logic. And then the Truck and Car sub-classes that include the custom repair logic for each of them.

However, whenever we need to make a change to the repair logic, we may need to change as many as three classes in this case. Instead, extracting the repair responsibility to its own mechanic class allows us to keep all the repair logic in a single place.

Responsibilities are vague

I chose this example because it is easy to see the divide in responsibilities here. However, because of the vagueness of the term “responsibility”, it sometimes becomes difficult to identify if a class is responsible for everything it is handling or if it needs to be split up.

Take, for example, a FileManager class. It is responsible for reading data from files and writing data to files.

This looks good, it is a file “manager” and it is responsible for managing everything to do with a file. But one may argue that these are two responsibilities, reading and writing and we could split it into two different classes, a reader and writer class.

So what to do?

So, which way is correct? Well, both. It depends on what you and your team agree on and what works for you. Writing code is more of an art than a science and these principles are a guideline and not a rulebook. Taking these to an extreme would again result in a codebase that is harder to understand and maintain.