Connascence of Execution

We’re starting our journey into dynamic connascence now, which is a bit trickier than static connascence. Dynamic connascence causes problems that you can’t necessarily see from the source code, as they require knowledge of how the program behaves whilst running. You can think of it as connascence that affects objects instead of connascence that affects classes.

Anyway, I hope you enjoyed the post on connascence of position, because connascence of execution is the dynamic equivalent. Connascence of execution refers to when multiple components must agree on the order of execution of code.

There are two main kinds of connascence of execution- sequential and adjacent. Sequential refers to when something must be done in a given order (Such as setting a recipient on an email before sending it), and adjacent refers to when something must be done without any intervening steps.

Let’s have a look at something that must be done in a given order:

Alright, everything looks fine so far- we have an enclosure that requires things to be done in the specific order in order to safely lock up a dinosaur. And we have a handler that agrees on this order and knows the right way to lock an enclosure.

If this was to ever change- say for a door needing to be locked before it could be primed, then both the enclosure and the handler would have to agree on the new order of execution, and both be changed at the same time to ensure correctness. And as connascence of execution is dynamic- we can only infer the behaviour from what happens at runtime, so it’s not as easy to track down and fix if we get something wrong.

To combat this, we need a way to transform our connascence of execution down to a lower level- preferably connascence of name. Let’s look at how we might do this:

Our DinosaurEnclosure now only exposes the correct action that can be taken next- like a state machine. A completely unlocked enclosure can only be locked, which returns a locked enclosure that can only be primed, which returns a primed enclosure that can only be electrified, which returns a safe enclosure that cannot be modified.

This has removed our connascence of execution, as it is no longer possible to execute the methods in the wrong order- the names of the classes and methods returned guarantee that, giving us connascence of name instead.

As connascence of execution is a dynamic connascence, it’s probably not a good idea to ever leave it alone where possible- they’re a lot harder to reason about from source code and tend to be a lot harder to fix if they go unchecked.


Author: Sean O'Toole

I like development and I like dinosaurs. Here we are.

Leave a Reply

Your email address will not be published. Required fields are marked *