This is a good example of a high-level responsibility, but I think it’s equally important to call out smaller scale responsibilities, because those are the ones that most developers will face most of the time.

A common example I see is putting a “printThisThing” method in a class, which generates a string-representation of the object and prints it out to stdout. Generating a string-representation of an object should not generally be it’s responsibility, you would want something like a “stringify” utility for doing that.

Any easy way to see this is to imagine some kind of simple class, such as one that represents a Car. You add a method to generate a string-representation of the car based on XML, and then the spec changes to say that you should be using JSON. Then it changes again to say you should be using YAML. This representation is a reason to change, but it doesn’t even deal with any of the actual business logic inside the class, e.g., the code dealing with the car. It’s therefore an additional responsibility that probably doesn’t belong in that class.

The same principle should also be applied at ever level of modularity: not just classes but upward to packages, and downward to function. Of course, the scale of “responsibility” changes as appropriate, otherwise you’d have a bunch of single-function classes in single-class packages, but the basic idea still applies.