Transform switches in maps

This article is about a recurring pattern you can apply while encountering chain of conditionals or switch statements.

Although their usage can be limited via polymorphism, switches will always creep in in Factories or at the boundaries of a system, where you do not have objects as inputs but only data structure coming from outside (an HTTP request, a database row, or a file to read). Polymorphism at least eliminates the duplication of these control structures and leave them in one clear place.

The presence of plain switch statements is however a problem: with this refactoring I propose to substitute the switches that cannot be modelled via polymorphism with a map approach.

For example, we cannot transform:

switch ($_GET['code']) {
    case 'A':
        $this->something();
        break;
    case 'B':
        $this->somethingElse();
        break;
}

in

$this->chosenController->action(); // $this->chosenController is an instance of A or B

because $_GET['code'] is coming from the HTTP request itself: if we move away the switch into a Factory it will still be present there, in order to choose a class to intantiate for $this->chosenController.

The theory

There are some advantages to switch statements elimination even if we can't model each branch with a different implementation of a certain object:

• we separate configuration from logic: the list of controllers here comprehends A, B and many other classes. We make clear what is part of a reusable object (we could name it a Router) and what is application-specific.
• As a consequence, when we add or remove cases we do not touch the tested code anymore. We just modify configuration.
• A corollary is that there are no false negatives in code coverage. While testing switches it's impossible to touch all branches, so we would be stuck with only covering a few ones and having to add repeated tests for the others if we want an high coverage.

The problem of refactoring from a switch to a map is that the code will be initially more difficult to read. But it's just because of a small learning curve.

Mechanics

Thus suppose we have this code (I omit the default branch for simplicity):

switch ($_GET['code']) {
    case 'A':
        $this->something();
        break;
    case 'B':
        $this->somethingElse();
        break;
}

Refactoring the switch to a map means to build an associative array (also called map or dictionary, depending on your language) where keys are functions of the input parameters and values are callbacks or objects that represent the action to take. In some simple cases (conversions), values are just scalars or objects.

The original switch becomes:

$self = $this;
$actions = array(
    'A' => function() use($self) { $self->something(); },
    'B' => function() use($self) { $self->somethingElse(); }
);
$action = $actions[$_GET['code']];
$action();

If a default branch is present, you will have to check with isset($actions[$_GET['code']]) before calling the action. Note also that in PHP 5.4 you can call directly $this->something() inside the closure.

In case all methods are similar, you can even simplify the map:

$actions = array(
    'A' => 'something',
    'B' => 'somethingElse'
);
$action = $actions[$_GET['code']];
$this->$action();

while if you have to just choose a value or an object is even simpler:

$actions = array(
    'A' => $something,
    'B' => $somethingElse
);
return $actions[$_GET['code']];

modulo error detection code.

Further refactoring

The simpler the configuration map, the easier it can be extracted and injected in the constructor of the object.

Dependency injection avoids hardcoding this configuration and lets you unit test the class without real configuration in it: we could easily test and develop from scratch a Router without calling actions from the real applications but just some Mocks.

Note that the more complex the configuration becomes, the more checks you should setup during injection; the reason is that it's easy to write down a not existent class or method name. Especially in dynamic languages, a map protects you from some of this errors:

$actions = array(
    'A' => new NotExistentClass(...),
    ...
);

because a single smoke test that covers these lines will reveal the culprit. A switch branch containing new NotExistentClass() in one of its branches will only generate an error if you're fortunate to execute that branch (and for full coverage this means all branches.)

You have to perform by yourself the more complex sanity checks for configuration instead:

foreach ($actions as $code => $a) {
    if (!is_callable($a)) {
        throw new Exception("The action for `$code` is not a callable object or closure. Check the configuration.");
    }
}

Conclusions

This refactoring may become an instance of Transform Conditionals Into Registrations (seen in the Object-Oriented Reengineering Patterns book), which builds a map dynamically instead of requiring configuration. In this version, multiple objects build a totally invisible configuration by registering themselves into an intermediate object like a Registry.

I maintain that central configuration is enough for many use cases, until you have a very high or dynamic number of actions or branches. It is also a smaller step when intervening on legacy code.

Thus pattern is not a way to substitute polymorphism, but just a smaller refactoring to apply to the most obnoxious switches at instantiation time or at boundaries, where objects have to be created from messages and external data structures.