As some of you may be aware I am currently writing a Compiler for Smalltalk that will output JVM bytecode. The compiler is in Java and as part of that compiler I have a large switch() statement which is very long (600+ lines) and in my opinion ugly and not OO. When I mentioned to a friend how the switch statement offended my sensibilities they replied “but it’s part of the language, so why not use it.” and it got me thinking about when to use it, when not to use it and more importantly how to write code that achieves the same result as a switch() but in a clean, readable, DRY way.
Two things I would like to make clear are that 1) the switch statement has a place but 2) it is not OO and in most every case it can and probably should be avoided.
When you need logic executed based on some facet/attribute of an object then the switch and the alternative approaches outlined can be applied.
To work though the pro’s and con’s and to show alternative approaches to a switch() we need to have an example to work through, so imagine we have to code a machine that prepares fruit. This machine takes a hopper of different fruits and depending on what fruit it is, slices, peels, juices it or a combination of these and puts the result in an output hopper. We are also working in Java which is a key point since other languages make it easier to avoid the switch() statement because they don’t have type erasure which happens when putting classes in a collection of a common base type. ie: when you take them out of the collection they have lost their type so you cant call overloaded methods with them.
Simplified, the core function of the machine might typically look like this with a switch statement:
handleFruit(List<Fruit> inputFruitHopper, List<Fruit> outputHopper) {
this.outputHopper = outputHopper;
for (Fruit fruit : inputFruitHopper)
handleFruit(fruit);
}
handleFruit(Fruit fruit) {
switch (fruit.type()) {
case APPLE: ...
case BANANA: ...
case PEAR: ...
case GRAPE: ...
case ORANGE: ..
default:
throw whatFruitIsThisException();
}
}
To me the problems with this approach are:
1) The handler has to have knowledge about some part of the Fruit in order to dispatch to the appropriate handling. This binds the dispatcher to the fruit which may seem like no big deal but:
1.1) it limits the ability to have a design that is more dynamic and that doesn’t have to change when new types of Fruit are added. ie: to support Kiwifruit you have to change the handleFruit(Fruit) method.
1.2) it locks in the mechanism for defining types of fruit (fruit.type()). We could use something else like the Class or a name as the switcher but the net effect is the same. 1.3) it exposes internals of fruit which voids information hiding, a principle of OO.
1.4) the tests for this method will be very large especially if they are to cover each case and the default case.
1.5) the possibility of reuse of this handler is very low, therefore you may have to write and test other dispatchers again and again. ie: if you had to weigh each fruit in a hopper would you want to code the same switch statement again?
1.6) switch() statements have a habbit of growing very large.
1.7) possibly the worst thing about this approach is that the logic for handling each type of Fruit is here within the handler who’s single responsibility (SRP) should be just the dispatching.
To me the benefits of this approach are:
1.8) It is said to be performant but I have not yet tested the performance of this approach over the others that can be used.
1.9) Im stuck on thinking of any other benefit.
There are alternatives to using a switch() which is what this post is all about and time permitting I’ll explore each of them at least briefly.
2) Use a Command Dispatch Pattern
The command pattern approach is where a hashtable of “command” objects is kept keyed on the Class of the expected objects. With this approach the handleFruit(Fruit) method could look like this:
handleFruit(Fruit fruit) {
FruitCommand fruitCommand = getHandlerFor(fruit.getClass());
if (fruitCommand == null)
throw whatFruitIsThisException();
fruitCommand.executeWith(fruit, outputHopper);
}
To me the benefits of this approach are:
2.1 The handler is short and easy to understand an test.
2.2 The handler doesn’t have to change to handle new types of Fruit.
2.3 The handler has a single responsibility, that of dispatching the Fruit to the appropriate command.
2.4 The logic to be applied to each fruit (slicing, peeling, juicing) is not part of the handler. This means new logic can be added without changing the handler.
2.5 While we use the Class of fruit to determine the command to be applied, we don’t expose the internals of the Fruit. There is a subtle difference between using a mechanism of the language and what we define as state/properties of a model. I see the former as less evil.
2.6 The testing of dispatcher and of each command is separated and therefore simpler.
2.7 This dispatcher could be generified with Java generics to be reused in other parts of the code.
To me the problems with this approach are:
2.8 The type of Fruit is still unknown to the command which will be required to ‘cast’ the Fruit to a subtype. ie: FruitCommand.executeWith(Fruit fruit, List<Fruit> outputHopper)
2.9 The switch statement did the dispatching and the registration of what logic (command) applies to what Fruit. In the command pattern approach this needs to be somewhere else, typically in an initialization mechanism, be it code or an IOC container.
2.10 It appears it would be less performant than a switch but I have not tested this.
2.11 As mentioned in 2.5 we use the Class of the object to lookup the command requiring each different Fruit to be a subtype. Personally I think they should be anyway - this is OO.
3) Use a Double Dispatch
This approach is where the object that is used to determine the logic to be applied is asked to call back on the dispatcher. This is how it might look:
handleFruit(Fruit fruit) {
fruit.callback(this);
}
To me the benefits of this approach are:
3.1) The handler is very simple.
3.2) The callback can be to a method on the dispatcher or a subclass of it that accepts the specific Fruit subtype. ie: the handler would have methods like: handle(Apple apple) So the logic gets the expected type without a cast.
3.3) It appears it would be faster than the Command Dispatch Pattern, but I have not tested this.
3.4) Code wise it is ‘neater’ then a large switch().
To me the problems with this approach are:
3.5 This is a very similar approach to the switch statement and would require changing the handler to
cater for new Fruit types.
3.6 The other negatives with the switch apply here as well, except for some of the testing concerns since each handler method can be tested independently of the rest of the dispatch logic.
3.7 There is now a direct binding between the Fruit and the dispatcher so it can make a callback. This can be made more subtle in a wrapper or subclass.
Conclusion
I have presented two alternatives to using a switch() statement and there are probably others. The key point I’m trying to make is that just because a language has a feature doesnt make it right to use it without consideration. What makes an approach “right” is a balance between readability, lowering duplication in code and effort, cost to change and lastly performance.
For my Smalltalk parser I still have a switch statement right now and after I have done some performance testing on the alternatives above and possibly others I will make a choice between the approaches, most likely favoring readability and simplicity. Which of the approaches is readable and simple to me may vary greatly to you which, makes for interesting conversations, but please don’t use a switch as a no thought default.
