RTTI
allows you to discover type information from an anonymous base-class handle.
Thus, it’s ripe for misuse by
the novice since it might make sense before polymorphic method calls do. For
many people coming from a procedural background, it’s difficult not to
organize their programs into sets of
switch
statements. They could accomplish this with RTTI and thus lose the important
value of polymorphism in
code development and maintenance. The intent of Java is that you use
polymorphic method calls throughout your code, and you use RTTI only when you
must.
However,
using polymorphic method calls as they are intended requires that you have
control of the base-class definition because at some point in the extension of
your program you might discover that the base class doesn’t include the
method you need. If the base class comes from a library or is otherwise
controlled by someone else, a solution to the problem is RTTI: You can inherit
a new type and add your extra method. Elsewhere in the code you can detect your
particular type and call that special method. This doesn’t destroy the
polymorphism and extensibility of the program because adding a new type will
not require you to hunt for switch statements in your program. However, when
you add new code in your main body that requires your new feature, you must use
RTTI to detect your particular type.
Putting
a feature in a base class might mean that, for the benefit of one particular
class, all of the other classes derived from that base require some meaningless
stub of a method. This makes the interface less clear and annoys those who must
override abstract methods when they derive from that base class. For example,
consider a class hierarchy representing musical instruments. Suppose you wanted
to clear the spit valves of all the appropriate instruments in your orchestra.
One option is to put a
ClearSpitValve( )
method
in the base class
Instrument,
but this is confusing because it implies that
Percussion
and
Electronic
instruments also have spit valves. RTTI provides a much more reasonable
solution in this case because you can place the method in the specific class (
Wind
in
this case), where it’s appropriate. However, a more appropriate solution
is to put a
prepareInstrument( )
method in the base class, but you might not see this when you’re first
solving the problem and could mistakenly assume that you must use RTTI.
Finally,
RTTI will sometimes solve efficiency problems. If your code nicely uses
polymorphism, but it turns out that one of your objects reacts to this general
purpose code in a horribly inefficient way, you can pick out that type using
RTTI and write case-specific code to improve the efficiency.