Responsibility Alignment

Whether the class name, responsibility, and attributes/functions line up. Given any two, we can evaluate the third. Given only one, we can't evaluate either of the others. I teach this as a design evaluation test. Out-of-alignment doesn't say which is wrong, it only says something is amiss. It follows that if you don't state the responsibility of the class, you can't run this test. --AlistairCockburn

Perhaps, sometimes, the responsibility of a class is best evaluated by seeing what it actually does, rather than what an independent document thinks it does. Quite often as one develops, one finds that the code pushes a class away from the responsibility one foresaw, to what the code really wants to do. See, for discussion, ToAyoungExtremist. --RonJeffries

I don't mind that - indeed, as you yourself have commented, sometimes when you look at the code, you eventually decide that the class has the wrong name. How would a person detect this? A name doesn't tell you much, but a name and a responsibility tell you a lot. As I wrote above, noticing that they are out of alignment doesn't say which is wrong - perhaps the name is wrong for that responsibility and code, perhaps the responsibility is wrong for that name and code, perhaps the code is wrong for that name and responsibility. So what you wrote is still part of the point of responsibility alignment. --Alistair

Yes, definitely. I didn't mean to seem to be disagreeing. Just remarking that the responsibility doesn't really have to be written down somewhere, it might be induced from what the code really does. In the original exposition you seem to be suggesting that the responsibility needs to be written down (other than in the class name). It's that assumption that I'd be willing to debate (but not willing to bet that I'd win the debate). ;-> --RonJeffries

So what are you evaluating? The name and the code? The name, the attributes list and the code? Which are you maybe going to decide is incorrect?

What about ManifestResponsibility?

Given any two, we can evaluate the third.

Isn't it likely that the attributes/functions evolve, and that the actual responsibility of the class changes over time, eventually leading to a renaming of the class (and, if documented, of the responsibility of that class). The period before that renaming, the class name, responsibility, and attributes/functions don't line up, but it's the first two that are wrong, not the single last one. I tried keeping class comments with responsibilities, but they mostly weren't used much and got out of date -- ArieVanDeursen

So what are you evaluating? The name and the code? The name, the attributes list and the code? Which are you maybe going to decide is incorrect?

The code says what the object does, ala TheSourceCodeIsTheDesign. If you extrapolate the responsibility of the object from the code (which is just as valid as looking it up in a separate document), is there any time when the name is going to be correct over the code?

If you're adding new functionality, it's a different story, I think. In this case, you've got new responsibilities in mind. This requires change to the code. How much change depends on how well the new responsibilities fit in with the old ones, I guess. In this case, it's clear that it's the code that's wrong: you've got new responsibilities, after all. Once you're finished, the code now contains the new responsibilities as well as the old ones. (MoveResponsibility? is clearly a refactoring).

In both scenarios (during development, and outside of development), there's no conflict on which is "right". If you're developing, the responsibilities are right (though you may have picked the wrong object to change). If you're not developing, the code is right. In both situations, if the name doesn't fit, it's clearly wrong.

If you're using TheSourceCodeIsTheDesign, you're never going to have a clash beyond a wrong name. It's only when you've got a separate definitive source for the responsibility that a clash is possible. ResponsibilityAlignment, to my mind, is something that will/should only happen when you're trying to determine which object(s) is the best fit for the new set of responsibilities/features that you're trying to implement. -- RobertWatkins.