TITLE: Type-tests, lists, and switch statements


PROBLEM: caj20721@uxa.cso.uiuc.edu (Chris Jasek)

Let's say I have a class hierarchy:

         Animal
         /  \
        /    \
      Dog    Cat

And then I create a list of Animals that contains Dog and
Cat class objects.  Of course when I get an item from the
list it must be returned as the base class type i.e. Animal.
From this pointer to an Animal that is returned there is no
way to access specific methods in either the Dog or Cat class.


RESPONSE: cvale@netcom.com (Chris Vale)

Assume Animal, Dog, and Cat have a memeber called isA. Then
Animal a = GetFromList();
switch( a.isA() ) {
CAT:
	do cat stuff
	break;
DOG:
	do dog stuff
	break;
}


RESPONSE: rmartin@rcmcon.com (Robert Martin), 17 Sep 93

The current standard provides a feature very similar to isA so that you can
ask an object what type it is.  This is sometimes useful.   However if
used generally, it leads to design problems.

In the Animal/Cat/Dog structure above, are there any common methods in
Animal?  If not, then Animal probably does not deserve to be a base
class.  If so, then the users of a list of Animal objects should
confine themselves to those methods.  If you have the need to operate
specifically upon Cats and Dogs, you should probably create a list of
Cats and a seperate list of Dogs

Let me stress that one of the fundemental benefits of OOP is the
ability to eliminate the kind of typeswitching shown in the example
above.  Such switches are maintenance bottlenecks since they must
constantly be found and updated whenever some new kind of animal is
added to the program. 

If you find yourself needing switch statments to test the type of an
object, then you should re-think your design.  Try to determine a
class hierarchy and abstract interface which will make the switch
irrelevent.  This is the *hard* part of OOD.