DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Data Engineering
  3. Databases
  4. Transform switches in maps

Transform switches in maps

Giorgio Sironi user avatar by
Giorgio Sironi
·
Aug. 29, 12 · Interview
Like (0)
Save
Tweet
Share
9.90K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Object (computer science) unit test Branch (computer science) Database

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Required Knowledge To Pass AWS Certified Solutions Architect — Professional Exam
  • Microservices Testing
  • Cucumber.js Tutorial With Examples For Selenium JavaScript
  • How To Best Use Java Records as DTOs in Spring Boot 3

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: