1. CMSC 202
Polymorphism

2. Inheritance and Polymorphism
Inheritance allows us to define a family of classes that share a common interface.
Polymorphism allows us to manipulate objects of these classes in a type-independent way.
We program the common interface through a pointer or reference to an (abstract) base class. The actual operation to invoke is not determined until run-time based on the specific type of object actually addressed.

3. C++ and Polymorphism
Polymorphism is the ability of a base class pointer (or reference) to refer transparently to any of its derived classes.
Polymorphism (and dynamic binding) are supported only when we use pointers (or references)

4. Inheritance and Pointers
A base class pointer can point to an object of a derived class
Derived class object “is-a” base class object
But can’t use pointer to call methods only defined in the derived class.
A derived class pointer CANNOT point to the base class
The base class doesn’t have any of the extensions provided by the derived class

5. Static vs. Dynamic Binding
The determination of which method in the class
hierarchy is to be invoked for a particular object.
Static (Early) Binding occurs at compile time
When the compiler can determine which method in the
class hierarchy to use for a particular object.
Dynamic (Late) Binding occurs at run time
When the determination of which method in the class
hierarchy to use for a particular object occurs during
program execution.

6. Static Binding
For example,
Time t1;
ExtTime et2;
t1.setTime(12, 30, 00); // static binding
et1.setExtTime(13, 45, 30); // static binding
t1.printTime( ); // static binding – Time’s printTime( )
et1.printTime(); // static binding – ExtTime’s printTime( )

7. Dynamic Binding Compiler cannot determine binding of object to method
Binding is determined dynamically at runtime
To indicate that a method is to be bound dynamically, the base class must use the reserved word virtual
When a method is defined as virtual, all overriding methods from that point on down the hierarchy are virtual, even if not explicitly defined to be so

8. A common example
class Shape { public: virtual void draw ( ) const = 0; // pure virtual virtual void error ( ); // virtual void objectID ( ); // non virtual };
void Shape::error ( ) { cerr << “Shape error” << endl; } void objectID ( ) { cout << “a shape” << endl; }

9. class Circle : public Shape { public:. virtual void draw( ) const;
class Circle : public Shape { public: virtual void draw( ) const; // method for drawing a circle virtual void error ( ); // overriding Shape::error …
}; void Circle::draw ( ) const { // code for drawing a circle } void Circle::error ( ) { cout << “Circle error” << endl; }

10. class Rectangle : public Shape { public:. virtual void draw( ) const;
class Rectangle : public Shape { public: virtual void draw( ) const; // method for drawing a rectangle … }; void Rectangle::draw ( ) const { // code to draw a rectangle }

11. Now consider these pointers: Shape. pShape; Circle
Now consider these pointers: Shape *pShape; Circle *pCircle = new Circle; Rectangle *pRectangle = new Rectangle; Each pointer has static type based on the way it’s defined in the program text.
The pointer’s dynamic type is determined by the type of object to which they currently refer.
pShape = pCircle; // pShape’s dynamic type is now Circle pShape->draw( ); // calls Circle::draw and draws a circle pShape = pRectangle; // pShape’s dynamic type is Rectangle pShape->draw ( ); // calls Rectangle::draw

12. An array of base class pointers
Shape *shapes[3];
shapes[0] = new Circle;
shapes[1] = new Rectangle;
shapes[2] = new Triangle;
for (int s = 0; s < 3; s++) shapes[s]->draw( );

13. A linked list of base class pointers
LinkedList<Shape * > shapes;
shapes.insert (new Circle);
shapes.insert (new Rectangle);
shapes.insert (new Triangle);
// traverse the list, printing each Shape in list

14. A simple ANIMAL hierarchy
DOG
CAT
WHALE
A simple ANIMAL hierarchy

15. class Animal { public:. Animal ( ) {name = “no name”, nrLegs = 0;}
class Animal { public: Animal ( ) {name = “no name”, nrLegs = 0;} Animal ( string s, int L) : name (s), nrLegs(L) { } virtual ~Animal ( ); virtual void speak ( ) const { cout << “Hi, Bob”; } string getName (void) const { return name; } void setName (string s) { name = s; } void setNrLegs (int legs) { nrLegs = legs;} int getNrLegs ( void ) const { return nrLegs;} private: string name; int nrLegs; };

16. class Dog : public Animal {
public: Dog ( ) : Animal (“dog”, 4), breed (“dog”) { } Dog (string s1, strings2) : Animal (s1, 4), breed (s2) { } ~Dog ( ); void setBreed (string s1) { breed = s1; } string getBreed (void ) const { return breed;} void speak ( ) const { cout << “Bow Wow ”; } void speak (int n) const { for (int j = 0; j < n: j++) speak ( ); } private: string breed; };

17. class Whale : public Animal {
public: Whale ( ); ~Whale ( ); private: };

18. main ( ) { Animal anAnimal (“Homer”, 2); Dog aDog (“Fido”, “mixed”); Whale aWhale (“Orka”); anAnimal.speak( ); aDog.speak( ); aDog.speak( 4 ); aWhale.speak( ) ; Animal *zoo[ 3 ]; zoo[0] = new Whale; zoo[1] = new Animal; zoo[2] = new Dog (“Max”, “Terrier”); for (int a = 0; a < 3; a++) { cout << zoo[a]->getName( ) << “ says: “ zoo[a] -> speak( ); } }

19. Works for functions too
Perhaps the most important use of polymorphism is the writing of functions to deal with all classes in the inheritance hierarchy. This is accomplished by defining the function parameters as pointers (or references) to base class objects, then having the caller pass in a pointer (or reference) to a derived class object. Dynamic binding calls the appropriate method.
These functions are often referred to as “polymorphic” functions.

20. drawShape( ) with a pointer
void drawShape ( Shape *sp) { cout << “I am “ ; sp -> objectID ( ); sp -> draw ( ); if (something bad) sp->error ( ); }
What is the output if drawShape( ) is passed a pointer to a Circle? a pointer to a Rectangle?
Circle: “I am a shape”, (objectID is nonvirtual) then the drawing of a circle.
if (something bad) then the output is “Circle Error” (error is virtual and overridden in Circle class)
Rectangle: “I am a shape”, (objectID is nonvirtual) then the drawing of a Rectangle
if (something bad) then the output is “Shape Error” (error is virtual, but NOT overridden in Rectangle)

21. drawShape ( ) via reference
void drawShape ( Shape& shape) { cout << “I am “ ; shape.objectID ( ); shape.draw ( ); if (something bad) shape.error ( ); }
What is the output if drawShape is passed a reference to a Circle? a reference to a Rectangle?
Same as with pointers in previous slide

22. Calling virtual methods from within other methods
Suppose virtual drawMe( ) is added to Shape and inherited by Rectangle without being overridden.
void Shape::drawMe ( void) {
cout << “drawing: “ << endl; draw( ); }

23. Which draw( ) gets called
From within drawMe( ) with this code?
Rectangle r1;
r1.drawMe ( );
The Rectangle version of draw( ), even though drawMe( ) was only defined in Shape. Why?
Because inside of drawMe( ), the call to draw( ) is really this->draw ( ); and since a pointer is used, we get the desired polymorphic behavior.

24. Don’t redefine objectID( )
Note that neither Circle nor Rectangle redefined the objectID( ) method which was a nonvirtual function. But what if they had?
Suppose the Rectangle class had it’s own version of objectID(). Consider this code: Rectangle R; // a Rectangle object Shape *pS = &R; // base class pointer to a Rectangle Rectangle *pR = &R; // derived class pointer to a Rectangle what is the output of the following? pS -> objectID ( ); pR -> objectID ( );
Both output “Shape Error” because objectID is NOT virtual, static binding occurs for Shape* pS
You DON’T get polymorphism as you expect with pS->objectID when pS points to a Rectangle
Bottom Line – don’t override nonvirtual functions

25. Old code and new code
In the procedural world (like that of C), it’s easy for new code to call old code using functions. However, it’s difficult for old code to call new code unless it’s modified to know about the new code.
In the OO world, old code (polymorphic functions) can dynamically bind to new code. This occurs when a new derived class is passed (by pointer or reference) to the polymorphic function. The polymorphic function needs no modification.

26. Don’t Pass by Value
A function which has a base class parameter passed by value should only be used with base class objects – for two reasons
The function isn’t polymorphic. Polymorphism only occurs with parameters passed by pointer or reference
Even though a derived class object can be passed to such a function (a D is-a B), none of the derived class methods or data members can be used in that function. This is a phenomenon called “member slicing”.

27. The same is true for assignment
Time t(10, 5, 0);
ExtTime et(20, 15, 10, ExtTime::EST);
A derived class object can be assigned to a base class
object
t = et; // legal, BUT Member slicing occurs.
A base class object cannot be assigned to a derived class
et = t; // illegal! Not all data members can be filled

28. Polymorphism and Destructors
A problem – if an object (with a non-virtual destructor) is explicitly destroyed by applying the delete operator to a base class pointer, the base class destructor is invoked. Circle C; Shape *sp = &C; delete sp; // calls Shape’s destructor // if the destructor is not // virtual
So what ??
So what – C++ standard says that this behavior is undefined
Compilers can do whatever they like, but most often the DC destructor is never called

29. Polymorphism and Destructors
Solution -- Declare a virtual destructor for any base class with at least one virtual function.
Then, when the derived class’s destructor is invoked, the base class destructor will also be invoked automatically

30. Designing A Base Class with Inheritance and Polymorphism in mind
For the base class
Identify the set of operations common to all the children
Identify which operations are type-independent (these become (pure) virtual to be overridden in derived classes)
Identify the access level (public, private, protected) of each operation
For a more complete discussion, see “Essential C++”, Stanley Lippman (section 5.4)