There was a question asked on the 97 Things Every Software Architect Should Know Linkedin group about coupling and cohesion that got me thinking.
My first response was to point to the video by +J. B. Rainsberger: Understanding Coupling and Cohesion. But this video didn't satisfactorily coupling and cohesion question.
As a follow up, heres what I wrote on the group, to solidify my understanding of coupling and cohesion, since it's not a topic that comes up directly during development.
Let me describe how I view coupling / cohesion, and see how it lines up with your understanding.
For me, coupling is the ease of which you can pull modules apart. You notice this when moving classes and functions around during refactoring. Until you make a change, you don't really feel the pain of tight coupling. To minimize this pain, you remove needless dependencies, depend on abstractions instead of concrete classes, pay attention to the law of demeter, etc (i.e. use good design, e.g. SOLID principles). You also notice tight coupling during unit testing. The more objects you have to mock out during a test is an indication that there are too many dependencies.
Cohesion is a measure of how well modules fit together. For me, this is a little harder to get a read on, but in general I think adhering to the single responsibility principle is a good way of increasing cohesion. I'm not as concerned with cohesion as I am with coupling. However, I like to review all the methods of a class during refactoring to ensure they all serve a single purpose, and all classes in a namespace fit together as well.
In my experience, low coupling and high cohesion are by products of good design. You don't set out with coupling / cohesion as design goals.
Patterns in Practice: Cohesion and Coupling by Jeremy Miller on MSDN seems like a good treatment of the topic.
How do you view coupling / cohesion, and how does it influence your coding?
Your post is fantastic; the insights provided are noteworthy. Fencing Services
ReplyDelete