what do I know

Cohesion and coupling are two terms that I always find myself coming back to when debating (with myself) over approaches to take to OO design. A definition for both cohesion and coupling can be found on Wikipedia. For the purpose of this series, I’m going to focus on each in the following regard:

 

Cohesion

Cohesion is the basic idea that a class has a focussed set of responsibilities, or behaviors, from a particular perspective. I gauge cohesion as an “analog-metric” from high to low. High cohesion implies focus, low implies a blurring of that focus.

Low |——————————–| High

Coupling

Coupling is a representation of a relationship between two classes and the degree to which they are dependent on each other. I gauge coupling as an “analog-metric” from loose to tight. Loose coupling implies easily interchangeable dependent classes, tight implies little to no interchangeability between dependent classes. Statically typed language typically rely on the use of interfaces to achieve loose coupling (segregating a class’ contractual agreement from its implementation of that agreement) where something like duck typing would be more commonly implemented in dynamic languages.

Tight |——————————–| Loose

 

Now Wikipedia probably does much better than I just did with these definitions, but the basic spirit of what I want to get across is in the above. Additionally, when I use the term “analog-metric” what I’m really trying to say is that through exposure to the design process and implementation of those designs, you gain a “code smell” for how a class can equate to one end of the spectrum or the other.

When working with my designs, I always try to keep one key point in my head:

Designing software with cohesion and coupling in mind is considered good practice, but designing for high cohesion and loose coupling in the purest sense can be harmful.

Now this might seem counter-intuitive at first. Why wouldn’t I strive to achieve the purest form of these “metrics” when designing my software? A lot of these reasons will become more evident over the next few posts, but suffice it to say, I feel there is a balance to be maintained when designing your software. Cohesion brought to its extreme may result in a code base that may be hard to maintain due to how large its become. An overly robust adherence to loose coupling could result in added flexibility to portions of a code base that may never be refactored over its lifetime.

I promise I’ll explain my perspective in more detail soon. For now, try to walk away from this post with an understanding of these two concepts and the variance that can exist in how they are gauged.

<< Part 1 : Introduction | Part 3 : Domains >>

Tags: oop

Related posts

• Frameworks Conference 2007 : Intro to Object Factories
• Frameworks Conference 2007 : Designing Framework-Agnostic Models with CFCs
• Frameworks Conference 2007 : Design Pattern Safari
• Does object persistence complicate architectures with existing data models?
• cf.objective() 2007 : OO Architecture Back to Front