Some Thoughts on Coupling

Submitted ⁨⁨8⁩ ⁨months⁩ ago⁩ by ⁨HamsterRage@programming.dev⁩ to ⁨programming@programming.dev⁩

https://www.pragmaticcoding.ca/java/coupling

I have a blog where I talk mostly about all things JavaFX, but this is one of the rare times that I write about something more general:

It’s All About (Loose) Coupling

I have about 35 years professional programming experience, and I’ve read literally millions of lines of code in that time. I’ve seen some great code, but mostly tons and tons of horrible code (a lot of that my own code from some time past) that I’ve been tasked with somehow fixing or enhancing. Over that time, I’ve often pondered what makes some code “good” and others “bad”.

My experience has shown me that excessive coupling is just about the worst thing that can happen to a code base in terms of sharing it and maintaining it. Yet, almost no new programmers (and a lot of experienced ones) seem to understand how important it is, and how to avoid it.

In this article, I review the kinds of coupling that I see all the time in projects that I look at. I try to explain how each type of coupling causes issues, how to recognize it and strategies to avoid or remove it.

Take a look, and let me know what you think.

source

Comments

Sort:hotnew top

catacomb@beehaw.org ⁨8⁩ ⁨months⁩ ago
I really liked how coupling is described as “knowing.” I find we talk about “does x need to know about y?” more than we do “is x overly coupled to y?” because the former is a relatable indicator of the latter.

source
benjhm@sopuli.xyz ⁨8⁩ ⁨months⁩ ago
I can relate to this, having developed a coupled socio-emissions-carbon-climate model, which evolved for 20 years in java, until recently converted to scala3. You can have a look here. The problem is that “coupling” in such models of complex systems is a ‘good’ thing, as there are feedbacks - for example atmospheric co2 drives climate warming but the latter also changes the carbon cycle, demography drives economic growth but the latter influences fertility and migration, etc… (some feedbacks are solved by extrapolating from the previous timestep - the delay is anyway realistic). There are also policy feedbacks - between top-down climate-stabilisation goals, and bottom up trends and national policies, the choice affects the logical calculation order. All this has to work fast within the browser (now scala.js - originally java applet), responding interactively to parameter adjustments, only recalculating curves which changed - getting all these interactions right is hard.
If restarting in scala3 I’d structure it differently, but having a lot of legacy science code known to work, it’s hard to pull it apart. Wish I’d known such principles at the beginning, but as it grew gradually, one doesn’t anticipate such complexity.

source