Ryan's District Boards

Computer, programming, and webmaster help , support , tips and tricks => Tutorials Zone! => Internet webmaster computer programming technology tips and tricks => C++ / C / C# ....Tutorials => Topic started by: ben2ong2 on October 07, 2006, 09:48:12 AM

Title: C++ tips - Type-tests, lists, and switch statements
Post by: ben2ong2 on October 07, 2006, 09:48:12 AM
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.