Is the SRP principle the same as "Low Coupling and High Cohesion"?
I was thinking about the Single Responsibility Principle - which roughly states that a class should only be responsible for one thing. (Is the word responsibility deliberately vague do you think!?)
Back in the software degree, we were taught that we should aim for Low Coupling and High Cohesion.
Basically, our units of code (classes and functions) should depend on as few other things as possible. This is low coupling.
To achieve high cohesion, we should keep related things together, so that code can be changed in as few places as possible.
I think that SRP is based on these principles. If an class has one responsibility, then it's cohesive because the code in that class focuses on a restricted set of purposes. If a class focuses on a restricted set of purposes, then it shouldn't need to be coupled to too many other things.
Conversely, if a class has many responsibilities then there is a good chance it will need to collaborate with lots of other classes (high coupling), and that it will contain code for lots of different things (low cohesion).
Thoughts?
Comments
-
To me, “low coupling and high cohesion”, and SRP, are like one of those “layout by springs” models, where the borders and the padding “push in” the components, but must allow them to “push back”. Which is to say, factoring one’s code right, is hard to do. Compare the v2 ‘division of labor’ with the v1 of anything to see what I mean. So SRP and lc&hc are like tests one can do on one’s code, as in “hc&lc instead? shit…” Problem is, they aren’t a solution, just a check mark. One still has to come up with that magical “correct factoring” in the first place. And, for v1, one probably won’t. Though SRP and lc&hc do “push” one the right way.
-
Hi @Peter
Nice analogy. Agree that they’re not solutions, just check marks, and I’m ok with that.
I often find that, as a sofware developer, I’m constantly looking for these checkmarks/guidelines that allow me to make some kind of objective judegement about my work. Software development often seems so artistic, chaotic and fuzzy, so finding hard rules is just plain HARD!
I wasn’t sure what you meant by the v1 ‘dividion of labour thing’ btw, can you ellaborate?