Static and dynamic analysis
How does Implicit Coupling relate to the various kinds of Connascence?
Last week I answered a couple of points from a Manchester-based Slack channel. That same Slack thread continued with another comment from Ross:
Is it safe to say the static section in your "handy cut out" is explicit coupling and the dynamic section is implicit ?
By “handy cut out” Ross is referring to my 2016 representation of the various kinds of Connascence:
These nine kinds of Connascence were identified by Meilir Page-Jones in his book Fundamentals of Object-oriented Design in UML, and I discussed Connascence at length in the article What Happened to Connascence?
Page-Jones suggests that the first five kinds of Connascence can be discovered through static analysis of the code, whereas the last four can only be discovered at runtime. Ross is thus asking whether the boundary between Explicit and Implicit Coupling lies at the same point as Page-Jones’s boundary between the static and dynamic kinds of connascence.
In response, the first thing I would note is that static analysis often requires an omniscient view of the codebase, whereas in these articles I want to steer the notion of Explicit Coupling towards always being local1. My working hypothesis is that the correspondence suggested by Ross doesn’t hold. But right now we’ve explored only a couple of code samples, and so I’m not prepared to make a commitment either way just yet. I believe we’ll need to explore many, many more examples of coupling before we can hypothesise that every example of Connascence of Algorithm, for example, can be viewed as Explicit Coupling.
Secondly, and as I wrote in What happened to Connascence?, it is by no means clear to me that every specific example of coupling can be assigned to exactly one kind of connascence. I believe that connascence is a great “starter kit” for helping to find coupling that might otherwise be difficult to see; but I don’t find connascence to be useful beyond that point. We’ve found some coupling — great, now let’s stop worrying about how we found it and instead focus on improving the habitability of our code.
To sum up, to my mind connascence and implicit vs explicit coupling are addressing different problems:
The Connascence catalogue can help us find coupling;
Implicit Coupling is how we decide whether we need to fix it; and
Explicit Coupling is about how we want the code to look after we’ve fixed it.
Of course, that’s (probably) a gross simplification. But I’ve confused huge numbers of people in the past by talking about Connascence as if it solves all of our problems on its own, so maybe a simplification is just what we need right now…
Please do keep sending me your questions, because by answering them I’m exploring my topic from your perspective. That’s really helping me to see past the things I’ve already skipped past or taken for granted, so thank you!
You can leave a question by commenting on any of these articles (button above 🙂), or by replying to your subscription email (you are subscribed, right?), or by messaging me via any of these means:
Twitter: @kevinrutherford
Next up, I plan to answer to Richard’s question about API coupling…
Have you thought about integration tests? That could solve some of the issues about the changing contracts
I wrote a few paragraphs about the omniscient view in Discount rules, some reflection, and I can see now that it probably deserves a few more pages devoted to it. In particular, what does “local” mean when encapsulation units are nested within other encapsulation units?