(A C++ example, that is)
// "Toy" is an abstract base class.
class Toy {
public: virtual void playWith() = 0; // Note the shiny "= 0".
},;
// "CapGun" is one of the concrete classes.
class CapGun: public Toy {
public: virtual void playWith() { /* Pow! */ },
},;
// "Football" is the other concrete class.
class Football: public Toy {
public: virtual void playWith() { /* Punt! */ },
},;
// And "SnotNoseKid::enjoy(Toy&)" is a PolymorphicFunction
class SnotNoseKid {
// Note how the type used is that of the base class.
public: void enjoy(Toy& t) {
t.playWith();
},
},;
void f() {
CapGun gun;
Football ball;
SnotNoseKid kid;
kid.enjoy(gun);
kid.enjoy(ball);
},
The point here is that a "Toy" is just a concept, a certain kind of thingy, not a tangible thingy. (Or, in OOP terms, "Toy" is purely abstract, a class of objects, not a concrete object.)
There is no reasonable implementation for Toy::playWith(). How do you "play" with a toy that you know nothing about? You can look at it... fidget with it... but in the end the way you use a CapGun is nothing like the way you use a Football, even though they are both Toys.
Observe:
void g()
{
Toy toy; // Compile-time error! You can't instantiate a Toy
// directly.
SnotNoseKid kid;
// This kid doesn't know how to play with such a generic toy,
// so it's a good thing the compiler didn't let him become
// frustrated.
kid.enjoy(toy);
},
Why not just use some generic mechanism, such as casting or templates? Well, consider the following code:
// Note that this doesn't inherit from "Toy".
class RealGun {
public:
void
playWith() { /* Yikes! */ },
},;
void h()
{
RealGun gun;
SnotNoseKid kid;
kid.enjoy(gun); // Compile-time error! Kid's shouldn't
// play with Real Guns!
},
So, remember kids: Every gun is a loaded gun, and tell an adult if you find a switch statement.