responsibility based modeling versus class reasons to change

Question

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)?

Answer 1

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.

1. It doesn't mean "1". It means "as few as possible".

2. 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.

3. Many simple things are better than a few complex things. It's easier to recombine and modify simple things.

4. Inside every complex thing are many simple things trying to be free.

5. It's hard to define "simple", but "one concept" is close. "one thing to change" is also a helpful test for "simplicity".

6. Finally, "one reason to change" doesn't literally mean "1".

Answer 2

The way I understand it, the danger of "glorifying a responsibility to a component" means that you need to be careful to not translate responsibilities to system components directly.

For example, in an email system, the user may approach the system with the goal of initiating a message to a recipient. It's the system's responsibility to make this possible.

The user may also approach the system to read and reply to an email. It's the system's responsibility to make this possible, too.

But does this mean that there need to be two components "initiate new email" and "reply to email" in the system? No. A general "compose email" component would be able to handle both requirements.

So in this case, the component "compose email" is responsible for the user goals "initiate new mail" and "reply to mail". But it would only need to change if its core concept changes ("how emails are composed").

Look again closely at the following phrase by Cockburn: "A component is supposed to capture an abstraction that has a purpose in the system". A purpose in the system (reason to change) is not the same as the purpose of satisfying a user goal (responsibility).

To make the long story short: As to my understanding, a component ideally has one core concept. It may have several responsibilities. But as I see it, the one responsibility may not be assigned to more than one component.