Making Your Code More Loosely Coupled

As programmers, we often talk about how it's better for components of an application to be isolated from each other. We recognize that, with our present programming tools, some level of coupling is unavoidable. We take it for granted, for example, that we have to use "signature coupling": To call a method we must know the method's name, the format of its parameter list and the data type of its return value.

But we also recognize that when we go beyond that level of coupling we start to create problems for ourselves. The primary problem is that, as components are more tightly coupled, changes in one component require changes in other components … and changes in those "other components" then require changes to still more components.

Where, I think, many developers don't realize that they've made their components too tightly coupled is in what's called "control coupling." Control coupling occurs when you pass a parameter to a method that controls the way the method behaves. The clue here is that inside a method you have an If statement (or some other conditional) that tests a parameter passed to the method and, based on that test, has the method do something different (other than, perhaps, throwing an exception because bad data was passed in the parameter).

Effectively, with control coupling, the code that calls a method is messing with the internal processing of that method. With this level of coupling any changes to how those control parameters are used (in either the method being called or in the calling code) are going to require changes to the other set of code.

The first step in reducing this level of coupling is to recognize that when you write code like this you're probably violating the separation of concerns principle: You have a method that does two things rather than doing one thing well. Your If statement is selecting between the two different things your method is doing. You're probably going to be better off to write two methods, each of which handles one piece of functionality.

There are two benefits here. First, all the versions of your method will now be much simpler. Simply eliminating an If statement cuts your method's complexity in half (after all, now there's only one path through the method to test). Second, when you want to change how things are done, you won't change any existing code. Instead, you'll write a new method that does the right thing and have your application call that method. By doing this, you avoid violating Vogel's first law of programming: Don't screw with working code!

If you feel that's going to make calling the right method hard to do, remember that you have options for simplifying that. Overloading will let you create multiple versions of a single method, each version of which is dedicated to handling a specific parameter list.

Moving code to classes derived from the same base class will let you hide different versions of the code behind the same signature (for example, the CreditCheck method does something different in PremiumCustomer than it does in DeadbeatCustomer). Any common code shared between the two versions can be put in the base class. You don't even need a base class: The Strategy and Role design patterns also allow you to put different implementations behind the same signature, as will effective use of interfaces.

If you value loose coupling, reducing control coupling might be your next step.

Posted by Peter Vogel on 02/26/2016