Avoid downcasting
Line 32: | Line 32: | ||
Thus downcasting strongly indicates problems with your class hierarchy (or interface). | Thus downcasting strongly indicates problems with your class hierarchy (or interface). | ||
+ | |||
+ | ==See Also== | ||
+ | |||
+ | [[Refactoring]]: [[Encapsulate Downcast]] |
Revision as of 04:43, 21 September 2008
Typically one downcasts when one has a collection of mixed objects of a certain superclass (for instance, several Cars, several Bicycles and several Trains, all subclasses of Vehicle). This is almost certainly the sub-optimal technique to accomplish your chosen task, because it's an indication (code smell) that you're not using polymorphism properly. The resulting code will inevitably have a Switch statement smell, another reason you should probably be restructuring your code.
Using our example, here's a pseudocode method that uses bad downcasting:
method turnonallvehicles() { foreach (Vehicle v in vehicleCollection) { if v is Car Car c = (Car)v c.turnKey() else if v is Bicycle Bicycle b = (Bicycle) v b.startPedalling() else if v is Train Train t = (Train) v t.lightCoal() } }
This clearly is disgusting. The problem here is that we are manually engaging a different method depending on the type, which means there is a problem relating to the superclass.
This means we are not taking advantage of polymorphism. The better way to go is this:
foreach (Vehicle v in vehicleCollection) { v.start() }
This would be the obvious technique if your superclass was defined correctly.
Thus downcasting strongly indicates problems with your class hierarchy (or interface).