In this text I read
Be alert for a component that is just a glorified responsibility. A component is supposed to capture an abstraction that has a purpose in the system. It may happen that what appears at one moment as a meaningful component is really just a single responsibility left on its own. That responsibility could be assigned to a component.
This confuses me. If a class should have only one reason to change, it seems like it should have one responsibility. But now it seems I'm taking this too narrow. Can somehow give an explanation of responsibility and reason to change in the context of responsibility based modeling? Can a class have more than two responsibilities and still have one reason to change (or the other way around)?
Read about Class-Responsibility-Collaboration modeling (or design)
http://www.agilemodeling.com/artifacts/crcModel.htm
http://alistair.cockburn.us/Using+CRC+cards
http://users.csc.calpoly.edu/~jdalbey/SWE/CaseStudies/ATMSim/CRCmodel.html
http://c2.com/doc/oopsla89/paper.html
A class may have several responsibilities. It always represents a single "thing".
The "one reason to change" rule doesn't apply to responsibilities. Period.
The "one reason to change" rule should be used as follows.
It doesn't mean "1". It means "as few as possible".
It applies to the "interface" or "underlying abstraction" or "concept" for a class. A class should encapsulate few concepts. When that the core concept changes, the class changes.
Many simple things are better than a few complex things. It's easier to recombine and modify simple things.
Inside every complex thing are many simple things trying to be free.
It's hard to define "simple", but "one concept" is close. "one thing to change" is also a helpful test for "simplicity".
Finally, "one reason to change" doesn't literally mean "1".