I've vastly misunderstood the Single Responsibility Principle

🔗 I've vastly misunderstood the Single Responsibility Principle
sicpers.info

So have a lot of other people; my understanding of it accords with much writing I've seen about the principle on the web, and elsewhere. For example, in Michael Feathers' "Working Effectively with Legacy Code":

Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.

Michael Feathers, Working Effectively with Legacy Code (p.246)

I came to question that understanding today when I read Parnas's article On the Criteria to be Used in Decomposing Systems into Modules. His top criterion is decision hiding: everywhere you make a choice about the system implementation, put that choice into a module with an interface that doesn't expose the choice made.

If you combine that principle with my incorrect SRP ("one reason to change per module"), you get the absurd situation that each module may contain only one change point. In other words, each bit of software architecture information must exist in a separate module.

continue reading on sicpers.info

⚠️ This post links to an external website. ⚠️

If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe use the RSS feed.