Know About Temporal Coupling – The Design Smell

Let’s first know what are code and design smells. Code smells are something that demonstrate bad coding practice, whose existence decreases the code quality, which shows the lack of design quality in the code. Code smells doesn’t affect your code from working properly, rather they are just absolute infringement of principals of developing a software. Whereas design smells are something that glows(sometime and sometimes not) as the violation of fundamental design principles, an example of design smell is temporal coupling.

Following are some common code smells which can be seen often:

1. Duplicate code: similar piece of code exists in more than one places.
2. Changing one class requires changes to some other class also.
3. Unnecessary comments: For e.g – adding comments for getters and setters, so on

Before moving on to temporal coupling, one should know the 2 indications of good software design and those are low coupling and high cohesion.
Cohesion: Putting parts of code base that are related to each other at one place.
Coupling: Keeping parts of code base that are unrelated to each other separate as much as possible.

What is temporal coupling?

Temporal means time based. So, consider if the time(instant/order) at which one member of a class is called, affects the calling of another member. Or, if sequence of calling members of a class is something that should be kept in mind before using that class’s member then it means they are coupled. For e.g – Consider the following class IronFist.

class IronFist {
    String fistColor;
    void fireFist() {
        System.out.println("Firing fist with color: " + this.fistColor);
    }
    void setFistColor(String color) {
        this.fistColor = color;
    }
}

Now, let’s say you want to instantiate this class and call the method fireFist() and then you want to change the color of the fist.

IronFist ironFist = new IronFist();
ironFist.fireFist();
ironFist.setFistColor("Red");

But do you think this would work? Obviously not, as it can be seen that “fistColor” is not set before the “fireFist()” is called. So, here we have introduced temporal coupling. One should be aware when he/she is calling “fireFist()” that “fistcolor” property is already set.

How to deal with temporal coupling?

Consider initializing “fistColor” while instantiating the class.

class IronFist {
    private String fistColor;

    public IronFist(String fistColor) {
        this.fistColor = fistColor;
    }
    void fireFist() {
        System.out.println("Firing fist with color: " + this.fistColor);
    }
    void setFistColor(String color) {
        this.fistColor = color;
    }
}

This way, we have handled a situation where one need not be worried about initializing the “fistColor” explicitly for the first time, before calling “fireFist()”. And this eventually took care of temporal coupling that we introduced above.

Why temporal coupling is critical?
Well, as you can see that in the above example where we have introduced coupling, the code seems to be fine and it will compile smoothly but it is definitely going to break during runtime. And dealing with compile time error is way affordable than runtime errors.

Another way of handling temporal coupling is introducing immutability. If there’s no shared/mutable state then there can be no temporal coupling. So, to make IronFist class immutable, we can remove setFistColor(). This way, we limit the mutation/initialization of object’s property to object creation and nowhere else.

Hope you’ve learnt something.