Polymorphism

Polymorphism
Having learned the basics of inheritance, creating an inheritance hierarchy, and
understanding that public inheritance essentially models an is-a relationship, it’s time
to move on to consuming this knowledge in learning the holy grail of object-oriented
programming: polymorphism. Program statements code: This is the part of a program
that performs actions and they are called methods.
In this lesson, you find out
? What polymorphism actually means
? What virtual functions do and how to use them
? What abstract base classes are and how to declare them
? What virtual inheritance means and where you need it
Basics of Polymorphism
“Poly” is Greek for many, and “morph” means form. Polymorphism is that feature of
object-oriented languages that allows objects of different types to be treated similarly.
This lesson focuses on polymorphic behavior that can be implemented in C++ via the
inheritance hierarchy, also known as subtype polymorphism.
Need for Polymorphic Behavior
In Lesson, “Implementing Inheritance,” you found out how Tuna and Carp inherit
public method Swim() from Fish as shown in example 1 of Lesson “Implementing
Inheritance". It is, however, possible that both Tuna and Carp provide their own
Tuna::Swim() and Carp::Swim() methods to make Tuna and Carp different swimmers.
Yet, as each of them is also a Fish, if a user with an instance of Tuna uses the base class
type to invoke Fish::Swim(), he ends up executing only the generic part Fish::Swim()
and not Tuna::Swim(), even though that base class instance Fish is a part of a Tuna .
This problem is demonstrated in Example 1.

Polymorphic Behavior Implemented Using Virtual Functions
You have access to an object of type Fish, via pointer Fish* or reference Fish&. This
object could have been instantiated solely as a Fish, or be part of a Tuna or Carp that
inherits from Fish. You don’t know (and don’t care). You invoke method Swim() using
this pointer or reference, like this:

Need for Virtual Destructors
There is a more sinister side to the feature demonstrated by Example1—
unintentionally invoking base class functionality of an instance of type derived, when
a specialization is available. What happens when a function calls operator delete using
a pointer of type Base* that actually points to an instance of type Derived?

Note that while Tuna and Fish were both constructed on the free store due to new,
the destructor of Tuna was not invoked on delete, rather only that of the Fish. This is
in stark contrast to the construction and destruction of local member myDinner where
all constructors and destructors are invoked. In the Lesson "Inheritance" we have
demonstrated the correct order of construction and destruction of classes in an
inheritance hierarchy, showing that all destructors need to be invoked, including
~Tuna(). Clearly, something is amiss.
This flaw means that code in the destructor of a deriving class that has been
instantiated on the free store using new would not be invoked if delete is called using
a pointer of type Base*. This can result in resources not being released, memory leaks,
and so on and is a problem that is not to be taken lightly.
To avoid this problem, you use virtual destructors as seen in Example 4.