I am quite confused with the Single Responsibility Principle. The Principle states that there should only be one reason for the class to change.
The problem which I am facing is, any change to a method or any logic change in doing things would change the class. For example, consider the following class:
class Person{
public void eat(){ };
public void walk(){ };
public void breathe(){ };
public void run(){ };
public void driveCar(Car car){ };
}
Uncle Bob describes it as there should ONLY be a single person/Actor responsible for the change. I have the following two questions:
- For the above class who is the actor/Person who can be responsible for change?
- Wouldn't any change in the logic of eating, breathing or walking change the class Person? So doesn't that mean that every method is a reason to change as it's logic to doing things might change?
What is a reason to change
- For the above class who is the actor/Person who can be responsible for change?
An Actor is: a user (including clients, stakeholders, developers an organizations) or an external system. We can argue if people are systems, yet that is nor here nor there.
See also: Use case.
- Wouldn't any change in the logic of eating, breathing or walking change the class Person? So doesn't that mean that every method is a reason to change as it's logic to doing things might change?
No, a method is not a reason to change. A method is something that can change... but why would it? What would trigger the developer to change it?
Part of the single responsibility principle is that code should interact at most with one external system. Remember that not all actors are external systems, however some are. I think most people will find this part of the SRP easy to understand, because an interaction with an external system is something we can see in the code.
However, that is not enough. For example, if your code has to compute taxes, you can hardcode the tax rate in your code. That way, it is not interacting with any external system (it is just using a constant). However, one tax reform later, the government has been revealed as a reason to change your code.
Something you should be able to do, is interchange external systems (perhaps with some additional coding effort). For example, changing from one database engine to another. However, we do not want one of these changes to translate into a total rewrite of the code. Changes should not propagate, and making a change should not break something else. To ensure that, we want all the code that deals with the database engine (in this example) to be isolated.
Things that change for the same reasons should be grouped together, things that change for different reasons should be separated.
-- Robert C Martin
We can do something similar with the government example above. We probably do not want the software reading the minute of the congress, instead we can have it reading a configuration file. Now the external system is the file system, and there would be code to interact with it, and that code should not interact with anything else.
How do we identify those reasons to change?
Your code is defined by a set of requirements. Some functional, others not. If any of those requirements change, your code have to change. A reason to change requirements is a reason to change your code.
Note: It is possible that you do not have all your requirement documented, however an undocumented requirement is still a requirement.
Then, you need to know from where do those requirements come from. Who or what could change them? Those are your reasons of change. It could be a change in the politics of the company, it could be a feature we are adding, it could be new law, it could be that we are migrating to a different database engine, or different operating system, translating to another language, adapting to another country, etc.
Some of those things are externals systems with which your code interacts (e.g. the database engine), some are not (the politics of the company).
What to do with responsibilities
You want to isolate them. So you will have code that interacts with the database, and nothing else. And you will have code that implement business rules, and nothing else. And so on.
Realize that even though the implementation of each part of your code will depend on something external, their interface does not have to. Thus, define interfaces and inject dependencies, so that you can change the implementation of each part without having to change the others… that is, the implementation of parts of your code should not be a reason to change the implementation of other parts of your code.
Note: No part of your code should have multiple responsibilities. Have parts of your code deal with each responsibility, and have part of your code with the responsibility of bringing other parts together. Similarly, if a part of your code has no responsibility… there is no reason to keep it. Thus, every part of your code should have exactly one responsibility.
For your code, ask yourself, what are the requirements of the Person class. are they complete? From where do they come from? Why would they change?
Recommended viewing
For a more authoritative explanation of the single responsibility principle, see Robert C Martin - The Single Responsibility Principle (51 minutes, 8 seconds, English language) at the Norwegian Developers Conference, 2015.
Interesting question. The quote from "Uncle Bob" Martin is:
A class should have one, and only one, reason to change.
One could interpret this as saying that your Person class has five reasons to change: you might want to change the eat method, or change the walk method, or the breathe method, or the run method, or the driveTheCar method. But this is too narrow, and doesn't really capture what Martin meant by a "reason to change".
A reason to change a class means a human programmer's motivation for changing it. You would not change the eat method simply because you were motivated to change the eat method; you would change it to achieve some goal regarding a desired behaviour of your program.
If the Person class models a person for some sort of simulation, then your motivation for changing it would be that you want "to change how people's actions are modelled in the simulation". Every change you make to the class would be motivated by that reason, whether you changed one method or more than one; so the Person class has only one "reason" to change, fulfilling the SRP.
If the Person class had some other methods such as for drawing the person on the screen, then you might also want "to change the graphical appearance of your simulated people". This would be a completely different motivation than the motivation to change the way your simulation models people's actions, so the class would have two responsibilities, violating SRP.
