Comments on: Back to Basics: Cohesion and Coupling Part 2

By: Ali Farhoudi

Ali Farhoudi — Fri, 25 Sep 2015 07:06:00 +0000

Thank you dear John Sonmez.
John Sonmez often likes to talk about “Back to Basics”, and I agree with him 100%. 😉

By: Clement

Clement — Thu, 11 Nov 2010 10:09:09 +0000

I love that feeling when I read a post and someone explains what I’ve been thinking for a while but never managed to, or had time to, write down and structure.
Good stuff. Unit tests and DI are too highly buzzed. Really, software engineering is about fashion.
Which is why we need to get “back to basics”.

The enterprise bus story, reminds me of a pattern used in WPF/Silverlight MVVM called event aggregator.

Any class can publish/subscribe to any events without caring about others. The problem is that it’s extremely hard to debug and to understand the flow, of who published/received the event.
BAD!

By: jsonmez

jsonmez — Wed, 10 Nov 2010 15:22:02 +0000

In reply to MrDustpan. I think SRP is closely related to cohesion. In my mind, SRP is something that helps us understand what things should be cohesive. All the things doing one responsibility should live together and belong to the same module. Cohesion and coupling are more of the how, and SRP is more of the why.

By: jsonmez

jsonmez — Wed, 10 Nov 2010 15:19:43 +0000

In reply to Samuel Jack. Excellent point. While in general a unit is a class, we shouldn't always assume it is.

By: MrDustpan

MrDustpan — Wed, 10 Nov 2010 14:37:02 +0000

Great series! Where does the Single Responsibility Principal fit into this? After reading your first post I figured that cohesion was basically the same concept as SRP, but now I’m not so sure.

By: Samuel Jack

Samuel Jack — Wed, 10 Nov 2010 11:39:09 +0000

John,
One lesson that I don’t think is well taught is picking the “right sized Lego blocks” when it comes to Unit Testing. When we started using TDD and DI two years ago, we assumed that “Unit” == “class”, so we have very fine-grained tests involving lots of mocks. This results in it being hard than it ought to refactor existing code, with the tests being more of a hindrance than a help.

Your point about picking the right “zoom level” is a good one. We don’t feel that we have to mock strings and arrays whenever we use them. Likewise we should pick the right zoom level for unit tests, and realise that sometimes a unit consists of several highly-cohesive classes.