Use the Strategy to avoid the Switch-Case antipattern

In PHP we have tons of bad constructs/functions that don’t actually help newcomers on writing good code: the SWITCH/CASE statement is one of those that I hate the most, although very few developers rely on it.

The statement is pretty straightfoward

Simple SWITCH/CASE statement
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php

class Logger
{
  public function logMessage($message = "CRITICAL::The system encountered a problem")
  {
      $parts = explode('::', $message);
      $level = $parts[0];

      switch ($level) {
          case 'notice':
              ...
              break;
          case 'critical':
              ...
              break;
          case 'catastrophe':
              ...
              break;
      }
  }

and is intended to make multiple IFs more readable.

It may seem useful, but at first you should recognize that multiple IFs are already a bad smell, so, from the beginning there is something with a code trying to make them look nicer.

The Strategy pattern, one of my favourites, is a simple but powerful way to avoid writing procedural code that relies on IFs.

The main concept is that you should contextualize the application’s workflow at runtime, deciding which steps (methods) to run based on data which is external to the method itself.

silly implementation of Strategy
1
2
3
4
5
6
7
8
9
10
11
<?php

class Logger
{
  public function logMessage($message = "CRITICAL::The system encountered a problem")
  {
      $parts  = explode('::', $message);
      $level  = $parts[0];
      $method = sprintf('log%sMessage', ucfirst($level));
      $output = $this->$method($parts[1]);
  }

In this way we are able to isolate and keep clean the implementations of the methods, thus the logic behind the application.

This means that we only need to implement submethods:

1
2
3
4
5
6
7
<?php

public function logNoticeMessage($message);

public function logCriticalMessage($message);

public function logCatastropheMessage($message);

If this doesn’t seem important to you, consider this scenario: you are shipping a library with the SWITCH/CASE in the first example; what would happen if another developer using that library would only like to edit the logic when a catastrophe message is received?

Yes, he would need to override the entire logMessage method, loosing the possibility to benefit of future software updates for that specific method.


Hi there! I recently wrote an ebook on web application security, currently sold on leanpub, the Amazon Kindle store and gumroad.

It contains 150+ pages of content dedicated to securing web applications and improving your security awareness when building web apps, with chapters ranging from explaining how to secure HTTP cookies with the right flags to understanding why it is important to consider joining a bug bounty program.

Feel free to skim through some of the free chapters published on this blog and, if the content seems interesting enough to you, grab a copy on leanpub, the Amazon Kindle store, gumroad or simply checkout right down below!

Buy the Web Application Security ebook for $6.99

In the mood for some more reading?

...or check the archives.