Max Berger

Polymorphism comes from greek:

Example: Odo from "Deep Space Nine"

In OO there are two definitions:

So what does that mean?

Example: Imagine a class for polygons:

Figure 9.1. A class for polygons

Sidenote: Remember derived attributs? area is a derived attribute.

If we where to look into the implementation of getArea() is would have to be very very very very very complicated to support any polygons.

Now how about some special cases of polygons?

Figure 9.2. Polygon with some subclasses

getArea() for Triangle and for Rectangle are very easy (for Hexagon it is still complicated). Can't we just redefine them for the subclasses with some more efficient algorithms? Yes, we can!

Figure 9.3. Polygon with subclasses that overwrite methods

Now we can implement an easier version of getArea() for Triangle and for Rectangle. We say "Rectangle overrides the method getArea()"

Rules for overriding:

Practice: Show an inheritance diagram of the classes "Aircraft", "Glider" and "Boing747". Assume that every aircraft has an operation "startEngines()". Boing747 will just use that operation. Glider will have to override it, since it has no engine.

Let's assume the following code:

twoDShape.getArea; // Book's notation
twoDShape->getArea(); // C++ notation

We may not know which algorithm gets executed, this depends on the Class that the object two2DShape belongs to. We have to look at several cases:

But how can I not know which class an object belongs to???

The answer is: Since every object is an instance of all of its superclasses, we can use it every place where we can use the superclass (Assignments, as parameters)! Here are some examples:

var p: Polygon;
var t: Triangle := Triangle.New;
var h: Hexagon := Hexagon.New;
...
if user sayas OK
then p := t
else p := h
endif;
...
p.getArea; // P may be a Triangle or a Hexagon object
...

Or in C++ notation:

Polygon *p;
Triangle *t = new Triangle();
Hexagon *h = new Hexagon();
...
if (userSaidOk)
  p = t;
else
  p = h;
...
p->getArea(); // P may point to a Triangle or a Hexagon
...

Even though we assign an object of class Triangle (or Hexagon) to an object handle for Polygons, the object will still keep its class, so it will still execute the getArea() function from Triangle (or Polygon in the case of Hexagon)

In classical programming we would need to test of what type p really is and have some complicated switch-statement.

Advantage: We can now add new classes that are subclasses of polygon and overwrite getArea() without changing any of the existing code!

The general declaration "var p:Polygon" (Polygon *p) is a safety restriction. It makes sure that:

The operation getArea() is an example of the first definition of polymorhpism.

The variable p is an example of the second definition of polymorphism.

Practice:

Assume the following classes:

Figure 9.4. Inhertiance diagram for Aircrafts

And the following code:

Aircraft *a = new Aircraft();
Boing747 *b = new Boing747();
Glider *g = new Glider();
...
a->startEngines(); 
b->startEngines(); 
g->startEngines(); 
...
a = g;
a->startEngines(); 
...
a = b;
a->startEngines(); 

which startEngines() functions are called in this code? Given an answer for the numbered lines.

Sidenote: Here we are losing an object, which one?

How does polymorphism work? Through dynamic binding:

The environment inspects the class at the last possible moment: at run-time, when the message is sent.

Do not confuse overriding with overrloading. Remember overloading from the intro class? We had function overloading and operator overloading.

Overriding: Superclass declares operation, subclass overrides it. Example: Aircraft declares startEngines(), Glider overrides startEngines().

Overloading: In the same class, but with different arguments! Example: Aircraft defines startEngines() and startEngines(toWhichPower:float).

Overloading is done by signature and can actually be checked at compile-time.

Some people (including me) sometimes call overloading polymorphism but that is incorrect! Only overriding is polymorphism.

Book: Chapter 1.8

Abstract operations

No we can override methods and declare superclasses with operations.

But what if an operation does not make sense on a superclass? What if the superclass is actually "useless" and just used for polymorhpism?

Figure 9.5. Example operation on vehicles

In this example, we would never instantiate an object of class "StreetVehicle". We would use the class StreetVehicle only to combine Motorcyle and Car. We would instantiate objects of class Car or Motorcycle and use them as StreetVehicle. The importance of every StreetVehicle is that is has an operation getCurrentSpeed() !

Then why even bother implementing getCurrentSpeed() on StreetVehicle? Instead, we can make it an abstract operation.

Important

abstract operation

An operation is lacking a a workable implementation. Normally, a descendent class will override this inherited abstract operation with its own concrete operation

Unfortunately, when a class has at least one abstact operation we will also need to make the class abstract

Important

abstract class

A class from which objects cannot be instantiated (normally because the class has one or more abstract operations). An abstract class is usually used as a source for descendant classes to inherit its concrete (nonabstract) operations.

The reason: Would we instantiate StreetVehicle and call its operation getCurrentSpeed(), but Streetvehicle does not implement it, we don't know what to do.

Abstract classes and operations are shown in UML in italics.

Figure 9.6. Vehicles with abstract superclass

Unfortunately you can not write italics on paper (you may be able to but I am not able to distinguish your italics from non-italics. Therefore if you want to denote abstract classes or operations in this class on paper, you have to use the stereotype <<abstract>>. I do not want you to write things like "this is italics" or something, since that would not be correct UML!

Figure 9.7. Abstract object as done on paper

The book uses an alternate notation. The use UML constraints (similar to stereotypes, but written in { } ) to denote abstract classes on paper. They would write {abstract}.

While stereotypes go in front of the method / class names, constraints go after the the declaration. Example: StreetVehicle {abstract}. See the book for an example.

You may use the books notation if you like or the stereotypes notation! But deceide on either one and do not mix them in the same diagram!

Book: Chapter 3.7

Practice: From the Vehicle example, draw an class diagram showing the classes Aircraft, Helicopter, and Plane. Add an operation getCurrentHeight() that is only defined for Helicopter and Plane, but specified on all Aircraft.

Pure abstract classes (interfaces)

A class that has has no attributes and only abstract operations is called a pure abstract class or interface.

Notes

• A pure abstract class may be a subclass of one or more pure abstract classes. (but not of abstract classes or regular classes).

• Since pure abstract classes define no attributes and only abstract operations they cause no problems with multiple inheritance

To denote a pure abstract class, you may use the stereotype <<interface>> on the class name. If you do your design on paper, thats enough. If you use a modelling tool you still have to italicize your class name and operations!

Practice: Draw a class diagram for the classes Chair, Table, Floor, and the pure abstract class Seat. Seat defines an operation sitOn() that the other three classes override.