Beware type switches
- Explicit case analysis on the type of an object is usually an error, the designer should use polymorphism in most of these cases. --Riel's Heuristic 5.12, Arthur Riel 1996
Type switches involve changing behaviour based on the object's type. Problems occur when multiple switches occur over the same variable in the same class, since when one is modified, all occurrences may need to be changed.
A possible solution is to replace any type code with a type class or Strategy pattern. See Martin Fowler's example at Replace Type Code With State/Strategy
Riel derived this idea from Johnson and Foote 1988: Eliminate case analysis
Example
To illustrate this imagine the following Player class, who could be of type "Knight", "Wizard" or "Elf"
The attack() method might operate as follows:
void attack(Creature creature) {
if(type.equals("Knight")) {
int damage = this.attackStrength - creature.toughness;
creature.lowerHealth(damage);
} else if (type.equals("Wizard")) {
int damage = this.attackStrength - creature.resilience;
creature.lowerHealth(damage);
} else //must be Elf
int damage = this.attackStrength - creature.armour;
creature.lowerHealth(damage);
}
}
Obviously this is bad from a maintenance point of view as every time a new Player type is added, the attack method needs to be changed. In a big game, this method could quickly become large. If a player type got removed, the appropriate section of this if-elseif-elseif...else block would need to be removed. Also, this does not support players changing weapons (there is no reason an elf couldn't use a sword if they wanted).
A better design would be to subclass Player, and override the (abstract) attack method in each subclass:
This is better as each attack method is small - it only has to deal with attacks from one particular player type. Also, when a new player type is added, the new attack method of that class will be used, without having to change anything in the Player superclass. Removing a player type is also easy - simply remove the class from the inheritance hierarchy, and again, no changes need to be made in the Player class. However, this is only one possible solution, and not necessarily the best (still has limited support for dynamically changing weapons/attacks within a player type). Another (and possibly better) solution is to use a strategy design pattern.
