For Coupling, Ask "Is There an Hidden Relationship?"

Today's code quality question pertains to coupling: "Is there a hidden relationship?"

The most dangerous kind of coupling is that which you don't know is there. If you find yourself writing some code and you can't explain why you're doing what you're doing just by reading the code around it or the tests, you probably have implicit coupling.

So be vigilant. As you write new code, maintain old code, or review others' code, ask the question "Is there a hidden relationship?"

This is a tricky one. You're not going to catch it all the time, at first. That's okay. If you can prevent 10% of the implicit coupling you otherwise would have written or clean up 10% of the implicit coupling you otherwise would have passed by unnoticed, it's a win.

For Coupling, Ask "Does This Express a Semantic Relationship?"

There are two kinds of relationships you can form from a class:

1. The fulfillment of a semantic need.
2. The exploitation of an implementation detail.

The former kind of relationship is far more resilient than the latter.

There are a lot of reasons why this is true.

The most compelling argument is the asymmetric relationship with change. A change to what you need invalidates an expression of both what to do and how to do it. A change to how something should be done, on the other hand, is unlikely to invalidate what need is being fulfilled.

So today's code quality question is "Does this express a semantic relationship?"

The Bizarre Properties of Coupling

Coupling is one of the easiest code qualities to mistake because of its unusual properties.

For one thing, Coupling doesn't require that you have to do the work to find the consequent change but t also doesn't preclude the possibility.

For another, coupling isn't always obvious.

For Coupling, Ask "How Intentional Is This Dependency?"

Coupling needs to be controlled. One way to do that is to evaluate whether or not any given instance of coupling is viable.

Today's code quality question is this: "How intentional is this dependency?"

Note, it's not about how intentional the dependency looks. It's about whether a dependency actually is something you meant to put in place or just an accidental tag-along from what you really wanted to use.

Control is the Goal with Coupling

The code qualities aren't all unconditionally good. Nor are they bad. They just are. The effects are good or bad but not the qualities, themselves.

Coupling is one of the greatest examples of this fact.

You can't set a goal of eradicating coupling because certain kinds of coupling are essential to software design. You can't set a goal of creating coupling because rampant coupling makes a system all but impossible to maintain.

A Brief Examination of Coupling

What is coupling, exactly?

A good working definition of coupling is as follows:

A certain kind of change to X triggers a corresponding change in Y