Dear Mr. Coplien,

thank you for your comment! I’m quite late with my response, but you gave me a long reading list and it took some time to catch-up.  And I still have to admit that I am yet not fully through this list as I only read Mr. Reenskaug’s publications as far to get to realize that there are many treasures yet to dig up.

I cannot object to the points you addressed, but I would like to add a few comments.

SOLID

I agree that the SOLID principles are simplified, but none-the-less they form a tool to help beginners to start caring about design. To my experience they are the first step for software developers on their journey of learning software design. And with many tools, if applied by the “non-thinking” person, these principles will not automatically lead to “good design” (I put this in quotes since I do not specify what good design is). Probably by giving the false impression of being on a safe track, they may indeed wreak havoc. This is similar to designs where software developers apply each and every design pattern they read about. But this does not make those patterns worthless.

Maybe you are objecting to the naming of SRP as “principle”, if principles have to lead automatically to desirable results. Maybe the wording should have been “guiding rule”?

So if I understand you correctly: The SRP is about class design (“There should never be more than one reason for a class to change.”) and therefore it will not lead to a good OO design, where you set focus on the element’s roles and their associated responsibilities.

I have to agree. But I wanted to point out that we shouldn’t abandon all of SOLID – which my impression is, your first paragraph is all about.

Responsibility

When you emphasize the fact that only roles have responsibilities, you certainly help to get software designers on the right track. Your comment helped me to see this more clearly.

On the other hand, if you state that no other entities (to be fair: in your comment you restrict this to classes and – in parts – objects only) can possibly have responsibilities, I’m lacking the vocabulary to document the justification for the existence of a particular element. I’m currently reading George Fairbanks’ book “Just enough Software Architecture”. He writes:

“As you design a system, you allocate responsibilities to system elements. You can allocate responsibilities to elements of any model in any viewtype. […] System elements can have both functional and quality attribute responsibilities.” (p. 251)

Again it makes sense to emphasize focusing on each element’s role and reason about this role’s responsibilities. But is saying that an element has a certain responsibility not just a shortcut? If a single line of code checks that a user is who he pretends to be, is it wrong to say that the responsibility of this line of code is authentication? So I still have no solution how I should describe that some element’s justification for existence is its ‘responsibility’ to fulfill a requirement. I continue having this gut feeling that the “One-Reason-to-Change” thing is helping to organize code (not objects). And there seems to persist my misunderstanding.

Conclusion

Finally, on the bottom line, in response to your comment, I will try to make it more clearly when I talk about OO design and when I’m addressing “technical issues”, try to address how these aspects are connected, and put focus on roles.

Of course I missed some things. God is in the details! Maybe I just have to continue reading and learning – well that’s certainly a sure bet. 

Thank you so much for your input!