

A slightly strange take on coupling and cohesion - KentBeck
http://www.threeriversinstitute.org/blog/?p=104

======
thalur
Certainly a very novel (to me) definition of coupling and cohesion - I had to
re-read the coupling section again, and I'm still not confident that I've
fully understood it.

I may have misunderstood, but I think its lacking the idea that change doesn't
necessarily propagate in both directions between two coupled elements. Taking
the wire protocol example from the article, you can change one endpoint
without that change propagating to the other, so long as you don't change the
protocol element which connects the two endpoints. This then highlights the
need for good abstractions and interfaces to break up the consequences of
making changes.

------
wallflower
I like the article because next time I have to explain to my manager why we
should 'zig' instead of 'zag', I can explain the cost of hasty or poor code
design in terms she understands (the long-term cost and pain).

~~~
stewiecat
Let me know how that goes. I've been trying to explain that to the
"architects" here, and they don't get it, let alone the other devs.

------
Silhouette
It's nice to see some acknowledgement (and reasoned argument) that smaller
isn't always better because there is increased complexity in the connections
between parts of the system. I'm fed up of people who've read no research and
learned their skills from Dogma University telling me or my team that we
should be using smaller functions and fewer levels of nesting and trivially
simple classes, because.

------
Femur
Going into it, I was expecting to read about girls and meaningful
relationships.

