Avoid downcasting

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
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).

See Also

Refactoring: Encapsulate Downcast

Personal tools