This is an AMP version of the article, its original content can be found here.
Temporal Coupling Between Method Calls
Temporal coupling happens between sequential method calls when they must stay in a particular order. This is inevitable in imperative programming, but we can reduce the negative effect of it just by turning those static procedures into functions. Take a look at this example.
Here is the code:
What do you think about that? I believe it's clear what
names() is doing—creating a list of names. In order to avoid duplication, there is a supplementary
append(), which converts an item to lowercase and adds it to the
This is poor design.
It is a procedural design, and there is temporal coupling between
lines in method
Let me first show you a better (though not the best!) design, then I will try to explain its benefits:
An ideal design for method
with() would create a new instance of
List, populate it through
add(item) to it, and
finally return. That would be perfectly
So, what is wrong with this:
It looks perfectly clean, doesn't it? Instantiate a list, append two items to it, and
return it. Yes, it is clean—for now. Because we remember what
doing. In a few months, we'll get back to this code, and it will look like this:
Is it so clear now that
append() is actually adding
will happen if I remove that line? Will it affect the result being
returned in the last line? I don't know. I need to check the body of method
append() to make sure.
Also, how about returning
list first and calling
append() afterwards? This
is what possible "refactoring" may do to our code:
First of all, we return
list too early, when it is not ready. But did anyone
tell me that these two calls to
append() must happen before
Second, we changed the order of
append() calls. Again, did anyone tell me
that it's important to call them in that particular order?
Nobody. Nowhere. This is called temporal coupling.
Our lines are coupled together. They must stay in this particular order, but the knowledge about that order is hidden. It's easy to destroy the order, and our compiler won't be able to catch us.
To the contrary, this design doesn't have any "order":
It just returns a list, which is constructed by a few calls to the
method. It is a single line instead of four.
As discussed before,
an ideal method in OOP must have just a single statement, and this statement is
The same is true about validation. For example, this code is bad:
While this one is much better:
See the difference?
And, of course, an ideal approach would be to use composable decorators instead of these ugly static methods. But if it's not possible for some reason, just don't make those static methods look like procedures. Make sure they always return results, which become arguments to further calls.