Tight Coupling

28 Jul 2022 · 4 min

I’ve heard people use “tight coupling” in many different ways, but often enough it is not really well understood. I found that using a new definition can help.

⭐ A new definition

According to Wikepedia Coupling is:

• the degree of interdependence between software modules
• a measure of how closely connected two modules are
• the strength of the relationships between modules

Although this is true, it is also vague. This is why I would like to use a slighly different definition:

Coupling is a measure of the knowledge required to interact successfully with an interface.

Lets have a look at an analogy to demonstrate what this means.

☕ Coffee machines

Up until about 10 years ago I used to make my morning coffee with a drip coffee maker.

Their interface is rather simple. To make coffee you need to:

1. Insert a filter and add coffee grind
2. Add water
3. Turn it on.
4. Wait
5. Enjoy your coffee

Around 10 years ago we bought an automatic coffee machine.

Operation is slightly different but not by much:

1. Add beans if required
2. Add water if required
3. Select the type of coffee you want
4. Wait
5. Enjoy your coffee

There is one important difference. When using the drip maker, the quality of your cup of coffee will depend on the amount of ingredients added. Too much grind, and the coffee will be too strong. Too little water and you wont have a full cup.

In other words, to successfully interact with the interface of the drip maker, you need to have the knowledge about how to use it.

In contrast, anyone using the automatic coffee maker will get the same result. This means that in order to successfully interact with the interface of any automatic coffee machine, you will just have to know which icon matches your prefered coffee type.

To make things worse, the amounts of ingredients for the “perfect cup” can differ per type of drip maker! If you ever need to get a new one, you will likely have to learn it all over again.

👩‍💻 Software interfaces

So how does this translate to interfaces in software?

As a simple example we will be calculating a person’s age. A tight coupled, simple interface would look like this:

long calculateAge(Person person);

To use this interface we have to know how to create a Person with it’s birthDate, to do that we probably need to know more about the person class itself.

In stead we could also look at the problem as the amount of full years passed since a person’s birthDate, and write the interface as:

long calculateYearsSince(Date date);

To use this interface we need to know how to create a Date. However, since this is a much more common problem, it is likely we already need this knowledge anyway and in this case we would also have needed it to create a Person. This means that the total knowledge required to successfully use the interface is less than for the previous one.

⚖ Is tight coupling bad?

In the early stages of any project, building something simple can be more important than building something extensible/re-usable. By building exactly and only what is needed now, the interface is likely to be both simple and coupled.

We can turn this around and say that a tight coupled interface is:

• Easier to design
• Easier to build
• Easier to understand

When there are multiple teams involved in a project, or the nature of the problem changes significantly, we will need to take into acount new use-cases and new consumers of the interface. We will see the following trade-offs:

A tight coupled interface is:

• Harder to change
• Less likely to be re-usable

💡 Conclusion

Tight coupling is a measure of the knowledge required to successfully use an interface. As long as there is only a single actor (dev/team) involved in both sides of the interface, tight coupling does not have to be a bad thing! The same knowledge will be needed on the implementation side anyway. Once multiple actors get involved, or if the nature of the problem solved by the interface changes significantly, tight coupling can cause problems.