For Encapsulation, Ask "What's the Cost of Changing Visibility Later?"

Most languages give you a choice regarding how visible a member of a class will be. The choices vary from language to language but, typically, they range from more-widely exposed options to those granting narrower visibility.

Every time you define a member, you are making this choice. Even if you take the default level of visibility, you are still making the choice to accept the implicit level of visibility.

One thing you can do to inexpensively start improving the level of encapsulation in your system is to start asking a simple question:

What's the cost of changing visibility later?

Generally, all levels of visibility have the same cost, initially. You aren't going to choose an access-modifier that prevents something from being used the first time you write it.

What really matters is how the level of visibility will interact with change. If you make something too private, now, how hard will it be to make it more public, later? If you make it too public, now, how hard will it be to change it to be more private, later?

In a lot of cases, it's pretty straightforward but it isn't always obvious. That's why it's worth asking the question.

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?"

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.

Code Quality Questions

If it hasn't already happened, you will eventually develop your own sensitivity to the various code qualities.

While you are practicing, though, it is useful to have concrete, diagnostic questions you can use to determine the health of your design decisions and to guide your future choices.

To that end, I will start writing a number of entries tagged "code qualities question". Each entry addresses a single question you can ask yourself to help you analyze a single aspect of a single code quality. These entries start today.