Advantages to Multiple Methods over Switch

Question

I received a code review from a senior developer today asking "By the way, what is your objection to dispatching functions by way of a switch statement?" I have read in many places about how pumping an argument through switch to call methods is bad OOP, not as extensible, etc. However, I can't really come up with a definitive answer for him. I would like to settle this for myself once and for all.

Here are our competing code suggestions (php used as an example, but can apply more universally):

class Switch {
   public function go($arg) {
      switch ($arg) {
         case "one":
            echo "one\n";
         break;
         case "two":
            echo "two\n";
         break;
         case "three":
            echo "three\n";
         break;
         default:
            throw new Exception("Unknown call: $arg");
         break;
      }
   }
}

class Oop {
   public function go_one() {
      echo "one\n";
   }
   public function go_two() {
      echo "two\n";
   }
   public function go_three() {
      echo "three\n";
   }
   public function __call($_, $__) {
      throw new Exception("Unknown call $_ with arguments: " . print_r($__, true));
   }
}

Part of his argument was "It (switch method) has a much cleaner way of handling default cases than what you have in the generic __call() magic method."

I disagree about the cleanliness and in fact prefer call, but I would like to hear what others have to say.

Arguments I can come up with in support of Oop scheme:

• A bit cleaner in terms of the code you have to write (less, easier to read, less keywords to consider)
• Not all actions delegated to a single method. Not much difference in execution here, but at least the text is more compartmentalized.
• In the same vein, another method can be added anywhere in the class instead of a specific spot.
• Methods are namespaced, which is nice.
• Does not apply here, but consider a case where Switch::go() operated on a member rather than a parameter. You would have to change the member first, then call the method. For Oop you can call the methods independently at any time.

Arguments I can come up with in support of Switch scheme:

• For the sake of argument, cleaner method of dealing with a default (unknown) request
• Seems less magical, which might make unfamiliar developers feel more comfortable

Anyone have anything to add for either side? I'd like to have a good answer for him.

Answer 1

A switch is considered not OOP because often polymorphism can do the trick.

In your case, an OOP implementation could be this:

class Oop 
{
  protected $goer;

  public function __construct($goer)
  {
    $this->goer = $goer;
  }

  public function go()
  {
    return $this->goer->go();
  }
}

class Goer
{
  public function go()
  {
    //...
  }
}

class GoerA extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerB extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerC extends Goer
{
  public function go()
  {
    //...
  }
}


$oop = new Oop(new GoerB());
$oop->go();

Answer 2

for this example:

class Switch
{
    public function go($arg)
    {
        echo "$arg\n";
    }
}

OK, only partially kidding here. The argument for/against the use of a switch statement cannot be strongly made with such a trivial example, because the OOP side depends on the semantics involved, not merely the dispatch mechanism.

Switch statements are often an indication of missing classes or classifications, but not necessarily. Sometimes a switch statement is just a switch statement.

Answer 3

Perhaps not an answer, but in the case of the non-switch code, it seems like this would be a better match:

class Oop {
  /**
   * User calls $oop->go('one') then this function will determine if the class has a 
   * method 'go_one' and call that. If it doesn't, then you get your error.
   * 
   * Subclasses of Oop can either overwrite the existing methods or add new ones.
   */
  public function go($arg){

    if(is_callable(array($this, 'go_'. $arg))){
      return call_user_func(array($this, 'go_'. $arg));
    }

    throw new Exception("Unknown call: $arg");
  }

  public function go_one() {
    echo "one\n";
  }
  public function go_two() {
    echo "two\n";
  }
  public function go_three() {
    echo "three\n";
  }
}

A big part of the puzzle to assess is what happens when you need to create NewSwitch or NewOop. Do your programmers have to jump through hoops by one method or the other? What happens when your rules change, etc.

Answer 4

Instead of just putting your executing code into functions implement a full command pattern and place each of them in their own class that implements a common interface. This method allows you to use IOC/DI to wire up the different "cases" of your class and allows you to easily add and remove cases from your code over time. It also gives you a good bit of code that doesn't violate SOLID programming principals.

Answer 5

I think the example is bad. If there is a go() function that accept argument $where, if's perfectly valid to use switch in the function. Having single go() function makes it easier to modify the behaviour of all go_where() scenarious. Additionally, you will preserve the class interface - if you use various methods, you are modifying the interface of the class with each new destination.

Actually switch should not be replaced with set of methods, but with set of classes - this is polymorphism. Then the destination will be handled by each subclass, and there will be single go() method for all of them. Replace conditional with polymorphism is one of the basic refactorings, described by Martin Fowler. But you may not need polymorphism, and switch is the way to go.