Advantages to Multiple Methods over Switch
- by tandu
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.
