The Dangers of Coupling and How to Avoid Them
This article is NWH, standing for Not Written Here. The concept of NWH is inspired from the NIH (Not Invented Here) syndrome which consists in refraining from using existing code from outside the company and reinventing the wheel every time. Just like it is good practice to look out for solutions developed elsewhere, we’re going to look at an article written elsewhere. Or said differently, an article that is NWH.
The NWH contents I present on Fluent C++ relate to the theme of writing better code, just like the homemade posts. It’s stuff I wish I could have written here. Or if their authors had submitted them here as guest posts I’d have gladly accepted them. So if you like the usual contents on Fluent C++, you’ll also like to discover the NWH.
The NWH of today is connasence.io. This website is a little perl that explains what coupling is, how to think about it and clear descriptions of the various types of coupling there are.
Coupling is a fundamental notion in programming, and a determining factor for the quality of your code. To understand what coupling is, consider the name of that website: “connascence”.
Connascence is the French word for knowledge (not quite with the right spelling that is connaissance, but anyway). It is about parts of the code that know about each other. And to be able to understand code and maintain it, you want its various part to be as independent from each other as possible. So connascence is bad, and coupling is bad.
But what makes connascence.io so interesting is that they go beyond this simple statement of coupling being bad. They categorise the various types of coupling that exist, showing that some are more harmful than others, some are unavoidable, and how to refactor a harmful coupling into a harmless one.
They suggest to measure coupling with three criteria, Strength, Degree and Locality, to “give the programmer all the tools they need in order to make informed decisions about when they will permit certain types of coupling, and when the code ought to be refactored.”
It takes about 30 to 45 minutes to read through the whole website, and each of those minutes is a good investment to improve our design skills.
Coupling is in my top 2 fundamental things with programming, the one at the top being respecting levels of abstraction. I feel that coupling and levels of abstraction are connected, but I was never able to express one in term of the other. Even though most programming best practices can be expressed in terms of respecting levels of abstraction.
So I have a little question for you: read connascence.io, read my post about respecting levels of abstraction, and tell me what you think: can you find an overarching principle that encompasses both of them? Or does one include the other? Or are they really two separate things?
Answer in a comment below.
You will also like
- How to Write Simple Code to Accomplish Complex Tasks
- Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost
- The Right Question for the Right Name
Share this post!
