Code Smell 123 - Mixed 'What' and 'How'

Maxi Contieri - Mar 22 '22 - - Dev Community

We love looking at the internal gears of the clock, but we need to start focusing on the hands.

TL;DR: Don't mess with implementation details. Be declarative. Not imperative.

Problems

  • Accidental Coupling

  • Coupling

  • Lack of design for change

  • Comments distinguish the 'how' and the 'what'.

Solutions

  1. Separate 'What' and 'How' concerns.

Context

Separating concerns is very difficult in the software industry.

Functional software survives ages.

Implementative software brings coupling and is harder to change.

Choosing wise declarative names is a daily challenge.

Sample Code

Wrong

class Workflow {
    moveToNextTransition() {
        // We couple the business rule with the accidental implementation
        if (this.stepWork.hasPendingTasks) {
            throw new Exception('Preconditions are not met yet..');
        } else {
            this.moveToNextStep();
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Right

class Workflow {
    moveToNextTransition() {
        if (!this.canWeMoveOn()) {
            throw new Exception('Preconditions are not met yet..');
        } else {
            this.moveToNextStep();
        }
    }

    canWeMoveOn() {
        // We hide accidental implementation 'the how'
        // under the 'what'
        return !this.stepWork.hasPendingTasks();
    }
}
Enter fullscreen mode Exit fullscreen mode

Detection

[X] Manual

This is a semantic and naming smell.

Tags

  • Readability

Conclusion

We need to choose good names and add indirection layers when necessary.

Of course, premature optimizators will fight us, telling us we are wasting computational resources and they need to know the insights we are hiding from them.

Relations

More Info

Credits

Photo by Josh Redd on Unsplash

The idea of this smell is here:

Code Smell 118 - Return False's comment

and here


We are constantly interfacing with other people's code that might not live up to our high standards and dealing with inputs that may or may not be valid. So we are taught to code defensively. We use assertions to detect bad data and check for consistency.

Andrew Hunt


This article is part of the CodeSmell Series.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .