Pathologies of Tight Coupling

We continue our conversation on code qualities with a discussion of why tight coupling is undesirable. Again, I want to stress, as I did in the last post, that we’re not striving for no coupling in a system. A system with no coupling is a system that does nothing. We want the right kind of coupling in the right places that gives us the flexibility we need but also allows us to apply the business rules we need in the right places.

Perhaps the worst kind of bad coupling in a system is global variables. Don’t get me started. I hate global variables, and I see a lot of them everywhere. They show up in all sorts of guises so most of you wouldn’t even recognize them as global variables. Do you use read-write singletons? Or service locators? Or value objects? These are all other names for global variables.

When I ask developers in my classes what they hate about global variables they usually tell me they hate that anyone can change them at any time. But to me, this is only a minor problem. To me, the big problem with global variables is that they hide dependencies. I can’t just look at the method signature and know what the method depends on. Somewhere inside that method, it’s going to make a call to a global resource and I will only know that if I read the method. So using global variables in a system requires anyone who wants to understand that system to read all of the code. But if I’m explicit about all of my dependencies then fellow developers can simply read my method signatures and see what my methods depend on.

Of course, we can’t and don’t want to eliminate global resources. It’s not that global state is bad. It’s just that it has to be managed and it also has to be understood. We should only use it when absolutely necessary and when it’s being used to represent some kind of a global resource.

Some things make sense as global resources, such as a global logging service as a write-only resource, a global registry as a read-only resource, and sometimes we even need to have resources that are read-write, such as a global registry of services. But if they’re global and they’re being shared among many clients then we have to design for that. There are many schemes and design patterns that help us with this and we have to find the right design for the particular usage we’re working with.

The other form of tight coupling that I see in programs all the time is what we call in the biz “magic numbers.” Magic numbers are numeric values that are used in code. Numbers in and of themselves don’t hold any context. The number 5 doesn’t mean anything other than signifying a quantity. So it’s far better to replace numbers with constants that represent the meaning of the number in the context for which it is being used. For example, MAX_USERS instead of the number 17. This makes the code far more readable and easier to work with.

These are basic, rudimentary services that a compiler offers and we should be taking advantage of them. We want our source code to be understandable when read, so I’ll either define constants within a class or define a class within a namespace that just holds constants. This is a simple technique that makes code far more readable.

Another source of bad coupling that I see in a system comes from writing overly generalized method signatures. We try to address the needs of several different clients by creating an uber-method that supports several different needs by passing in several different kinds of data. This is generally a bad practice. Instead, each type of client should have its own API with its own specialized interface that it can call as needed. Multiple client types should have their own entry points and their own specialized set of parameters. This helps segregate clients and limits accidental coupling. These front-end APIs can then share code internally on the back-end, as needed.

But perhaps the worst form of coupling to me is what I call split functionality. This happens when, for whatever reason, a single process is broken out into two or more parts and those different parts then have to be kept in sync with each other. If this form of coupling is broken, it causes a bug to happen. We can fix this type of poor coupling by bringing the parts together into one central place.

So, while too much coupling is bad, too little coupling can also be a problem.