Polymorphism

Chapter 12

Polymorphism

The term polymorphic has Greek ro ots and means roughly \many forms." poly = many,

morphos = form. Morphos is related to the Greek go d Morphus, who could app ear to

sleeping individuals in any form he wished and hence was truly p olymorphic. In biology,a

p olymorphic sp ecies is one, suchasHomo Sapiens, that is characterized by the o ccurrence

of di erent forms or color typ es in individual organisms or among organisms. In chemistry,

a p olymorphic comp ound is one that can crystallize in at least two distinct forms, suchas

carb on, which can crystallize b oth as graphite and as diamond.

12.1 Varieties of Polymorphism

In ob ject-oriented languages, p olymorphism is a natural result of the is-a relationship and of

the mechanisms of message passing, inheritance, and the concept of substitutability. One of

the great strengths of the OOP approach is that these devices can b e combined in a variety

of ways, yielding a numb er of techniques for co de sharing and reuse.

Pure polymorphism o ccurs when a single function can be applied to arguments of a

varietyoftyp es. In pure p olymorphism, there is one function co de b o dy and a number

of interpretations. The other extreme o ccurs when wehavea numb er of di erent functions

co de b o dies all denoted by the same name{a situation known as overloading or sometimes

ad hocpolymorphism. Between these two extremes are overriding and deferred methods.

Note that there is little agreement regarding terminology in the programming language commu-

nity. In [Horowitz 1984 ], [Marcotty 1987 ], [MacLennan 1987 ], and [Pinson 1988 ] for example, polymor-

phism is de ned in a manner roughly equivalent to what we are here calling overloading. In [Sethi 1989 ]

and [Meyer 1988a ] and in the functional programming languages community such as [Wikstrom 1987 ,

Milner 1990 ], the term is reserved for what we are calling pure polymorphism. Other authors use the

term for one, two, or all of the mechanisms describ ed in this chapter. Two complete, but technically

daunting, analyses are [Cardelli 1985 ] and [Danforth 1988 ]. 207

208 CHAPTER 12. POLYMORPHISM

12.2 Polymorphic Variables

With the exception of overloading, p olymorphism in ob ject-oriented languages is made p os-

sible only by the existence of polymorphic variables and the idea of substitutability. A

p olymorphic variable is one with many faces; that is, it can hold values of di erenttyp es.

Polymorphic variables emb o dy the principle of substitutability. In other words, while there

is an exp ected typ e for anyvariable the actual typ e can b e from anyvalue that is a subtyp e

of the exp ected typ e.

In dynamically b ound languages such as Smalltalk, all variables are p otentially p olymorphic{

anyvariable can hold values of anytyp e. In these languages the desired typ e is de ned by

a set of exp ected b ehaviors. For example, an algorithm may make use of an arrayvalue,

exp ecting the subscripting op erations to be de ned for a certain variable; any typ e that

de nes the appropriate b ehavior is suitable. Thus, the user could de ne his or her own typ e

of array for example, a sparse array and, if the array op erations were implemented using

the same names, use this new typ e with an existing algorithm.

In statically typ ed languages, suchasJava, the situation is slightly more complex. Poly-

morphism o ccurs in Java through the di erence between the declared static class of a

variable and the actual dynamic class of the value the variable contains.

A good example of a p olymorphic variable is the array allPiles in the Solitare game

presented in Chapter 9. The arraywas declared as maintaining a value of typ e CardPile,

but in fact it maintains values from each of the di erent sub classes of the parent class. A

message presented to a value from this array, such as display in the example co de shown

b elow, executes the metho d asso ciated with the dynamic typ e of the variable and not that

of the static class.

public class Solitaire extends Applet f

...

static CardPile allPiles [ ];

...

public void paintGraphics g f

for int i = 0; i < 13; i++

allPiles[i].displayg;

...

12.3 Overloading

Wesay a function name is overloaded if there are two or more function b o dies asso ciated

with it. Note that overloading is a necessary part of overriding, whichwe and will describ e

12.3. OVERLOADING 209

in the next section, but the two terms are not identical and overloading can o ccur without

overriding.

In overloading, it is the function name that is p olymorphic{it has many forms. Another

way to think of overloading and p olymorphism is that there is a single abstract function

that takes various typ es of arguments; the actual co de executed dep ends on the arguments

given. The fact that the compiler can often determine the correct function at compile time

in a strongly typ ed language, and can therefore generate only a single co de sequence are

simply optimizations.

12.3.1 Overloading Messages in Real Life

In Chapter 1 wesaw an example in whichoverloading o ccurred without overriding, when

Iwanted to surprise my friend with owers for her birthday. One p ossible solution was to

send the message sendFlowersTo to my lo cal orist; another was to give the same message to

my wife. Both my orist and my wife an instance of class Sp ousewould have understo o d

the message, and b oth would have acted on it to pro duce a similar result. In a certain sense,

I could have thoughtofsendFlowersTo as b eing one function understo o d by b oth my wife

and my orist, but eachwould have used a di erent algorithm to resp ond to my request.

Note, in particular, that there was no inheritance involved in this example. The rst

common sup erclass for my wife and my orist was the category Human. But certainly the

b ehavior sendFlowersTo was not asso ciated with all humans. My dentist, for example, who

is also a human, would not have understo o d the message at all.

12.3.2 Overloading and Co ercion

As an example more closely tied to programming languages, supp ose a programmer is devel-

oping a library of classes representing common data structures. Anumb er of data structures

can b e used to maintain a collection of elements sets, bags, dictionaries, arrays, and priority

queues, for example, and these might all de ne a metho d, add, to insert a new elementinto

the collection.

This situation{in whichtwo totally separate functions are used to provide semantically

similar actions for di erent data typ es{o ccurs frequently in all programming languages, not

simply in ob ject-oriented languages. Perhaps the most common example is the overloading

of the addition op erator, +. The co de generated by a compiler for an integer addition is often

radically di erent from the co de generated for a oating-p oint addition, yet programmers

tend to think of the op erations as a single entity, the \addition" function.

In this example it is imp ortant to p oint out that overloading may not b e the only activity

taking place. A semantically separate op eration, coercion, is also usually asso ciated with

arithmetic op erations. It o ccurs when a value of one typ e is converted into one of a di erent

typ e. If mixed-typ e arithmetic is p ermitted, the addition of twovalues maybeinterpreted

in a numb er of di erentways:

210 CHAPTER 12. POLYMORPHISM

There may b e four di erent functions, corresp onding to integer + integer, integer +

real, real + integer, and real + real. In this case, there is overloading but no co ercion.

There maybetwo di erent functions for integer + integer and real + real. In integer

+ real and real + integer, the integer value is co erced by b eing changed into a real

value. In this situation there is a combination of overloading and co ercion.

There may b e only one function, for real + real addition. All arguments are co erced

into b eing real. In this case there is co ercion only, with no overloading.

12.3.3 Overloading from Separate Classes

There are two di erent forms of overloading that can be distinguished. One form o ccurs

when the same function name is found in two or more classes that are not linked by inher-

itance. A second form o ccurs when two or more functions with the same name are found

within one class de nition. The latter form will b e describ ed in the next section.

A good example of overloading of the rst typ e is the metho d isEmpty. This metho d

is used to determine if an ob ject is empty,however the exact meaning of empty will di er

dep ending up on circumstances. The message is understo o d by the classes Vector, Hashtable

and Rectangle. The rst two are collection classes, and the message returns true when there

are no elements in the collection. In the class Rectangle the message returns true if either

the height or width of a rectangle is zero, and thus the rectangle has no area.

Rectangle r1 = new Rectangle ;

if r1.isEmpty ...

Overloading Do es Not Imply Similarity

There is nothing intrinsic to overloading that requires the functions asso ciated with an

overloaded name to have any semantic similarity. Consider a program that plays a card

game, such as the solitaire game we examined in Chapter 9. The metho d draw was used to

draw the image of a card on the screen. In another application we might also have included

a draw metho d for the pack of cards, that is, to draw a single card from the top of the deck.

This draw metho d is not even remotely similar in semantics to the draw metho d for the

single card, and yet they share the same name.

Note that this overloading of a single name with indep endent and unrelated meanings

should not necessarily b e considered bad style, and generally it will not contribute to con-

fusion. In fact, the selection of short, clear, and meaningful names suchasadd, draw, and

so on, contributes to ease of understanding and correct use of ob ject-oriented comp onents.

It is far simpler to rememb er that you can add an element to a set than to recall that to

do so requires invoking the addNewElement metho d, or, worse, that it requires calling the

Mo dule Addition Metho d. routine Set

12.4. OVERRIDING 211

All ob ject-oriented languages p ermit the o ccurrence of metho ds with similar names in

unrelated classes. In this case the resolution of overloaded names is determined by obser-

vation of the class of the receiver for the message. Nevertheless, this do es not mean that

functions or metho ds can b e written that take arbitrary arguments. The statically typ ed

nature of Java still requires sp eci c declarations of all names.

12.3.4 Parameteric Overloading

Another style of overloading, in which pro cedures or functions or metho ds in the same

context are allowed to share a name and are disambiguated by the number and typ e of

arguments supplied, is called parameteric overloading; it o ccurs in Javaaswell as in some

imp erative languages such as Ada and many functional languages. Parameteric overload-

ing is most often found in constructor functions. A new Rectangle, for example, can be

created either with no arguments generating a rectangle with size zero and northwest cor-

ner 0,0, with two integer arguments a width and height, with four integer arguments

width, height, northwest corner, with a Point the northwest corner, size is zero, with a

Dimension height and width, corner 0,0, or with b oth a Point and a Dimension.

Rectangle r1 = new Rectangle ;

Rectangle r2 = new Rectangle 6, 7;

Rectangle r3 = new Rectangle 10, 10, 6, 7;

Point p1 = new Point 10, 10;

Dimension d1 = new Dimension 6, 7;

Rectangle r4 = new Rectangle p1;

Rectangle r5 = new Rectangle d1;

Rectangle r6 = new Rectangle p1, d1;

There are six di erent constructor functions in this class, all with the same name. The

compiler decides which function to execute based on the number and typ e of arguments

used with the function call.

Overloading is a necessary prerequisite to the other forms of p olymorphism we will

consider: overriding, deferred metho ds, and pure p olymorphism. It is also often useful in

reducing the \conceptual space," that is, in reducing the amountof information that the

programmer must rememb er. Often, this reduction in programmer-memory space is just as

signi cant as the reduction in computer-memory space p ermitted by co de sharing.

12.4 Overriding

In Chapter 8 we describ ed the mechanics of overriding, so it is not necessary to rep eat that

discussion here. Recall, however, the following essential elements of the technique. In one

class typically an abstract sup erclass, there is a general metho d de ned for a particular

212 CHAPTER 12. POLYMORPHISM

message that is inherited and used by sub classes. In at least one sub class, however, a metho d

with the same name is de ned, that hides access to the general metho d for instances of this

class or, in the case of re nement, subsumes access to the general metho d. We say the

second metho d overrides the rst.

Overriding is often transparent to the user of a class, and, as with overloading, frequently

the two functions are thought of semantically as a single entity.

12.4.1 Replacement and Re nement

In Chapter 9 we brie y noted that overriding can o ccur in two di erent forms. A metho d

can replace the metho d in the parent class, in which case the co de in the parent is not

executed at all. Alternatively, the co de from the child can b e used to form a re nement,

which combines the co de from the parent and the child classes.

Normally,overridden metho ds use replacement semantics. If a re nement is desired, it

can b e constructed by explicitly invoking the parent metho d as a function. This is accom-

plished by using the pseudo-variable sup er as the receiver in a message passing expression.

An example from the Solitare program describ ed in Chapter 9 showed this:

class DiscardPile extends CardPile f

public void addCard Card aCard f

if ! aCard.faceUp

aCard.flip;

super.addCardaCard;

Constructors, on the other hand, always use re nement semantics. A constructor for a

child class will always invoke the constructor for the parent class. This invo cation will take

place before the co de for the constructor is executed. If the constructor for the parent class

requires arguments, the pseudo-variable sup er is used as if it were a function:

class DeckPile extends CardPile f

DeckPile int x, int y f

// rst initialize parent

superx, y;

// then create the new deck

// rst put them into a lo cal pile

for int i = 0; i < 4; i++

for int j = 0; j <= 12; j++

12.5. ABSTRACT METHODS 213

addCardnew Cardi, j;

// then shue the cards

Random generator = new Random;

for int i = 0; i < 52; i++ f

int j = Math.absgenerator.nextInt 52;

// swap the two card values

Object temp = thePile.elementAti;

thePile.setElementAtthePile.elementAtj, i;

thePile.setElementAttemp, j;

When used in this fashion, the call on the parent constructor must b e the rst statement

executed. If no call on sup er is make explicitly and there exist two or more overloaded

forms of the constructor, the constructor with no arguments sometimes called the default

constructor will b e the form used.

12.5 Abstract Metho ds

A metho d that is declared as abstract can b e thought of as de ning a metho d that is deferred;

it is sp eci ed in the parent class but must b e implemented in the child class. Interfaces can

also be viewed as a metho d for de ning deferred classes. Both can be considered to be

a generalization of overriding. In b oth cases, the b ehavior describ ed in a parent class is

mo di ed by the child class. In an abstract metho d, however, the b ehavior in the parent

class is essentially null, a place holder, and al l useful activity is de ned as part of the co de

provided by the child class.

One advantage of abstract metho ds is conceptual, in that their use allows the program-

mer to think of an activity as asso ciated with an abstraction at a higher level than may

actually b e the case. For example, in a collection of classes representing geometric shap es,

we can de ne a metho d to draw the shap e in each of the sub classes Circle, Square, and

Triangle. We could have de ned a similar metho d in the parent class Shap e, but such a

metho d cannot, in actuality, pro duce any useful b ehavior since the class Shap e do es not

have sucient information to draw the shap e in question. Nevertheless, the mere presence

of this metho d p ermits the user to asso ciate the concept draw with the single class Shap e,

and not with the three separate concepts Square, Triangle, and Circle.

There is a second, more practical reason for using abstract metho ds. In statically typ ed

ob ject-oriented languages, suchasJava, a programmer is p ermitted to send a message to an ob ject only if the compiler can determine that there is in fact a corresp onding metho d

214 CHAPTER 12. POLYMORPHISM

that matches the message selector. Supp ose the programmer wishes to de ne a p olymorphic

variable of class Shap e that will, at various times, contain instances of each of the di erent

shap es. Such an assignment is p ossible, according to our rule of substitutability; neverthe-

less, the compiler will p ermit the message draw to b e used with this variable only if it can

ensure that the message will b e understo o d byanyvalue that may b e asso ciated with the

variable. Assigning a metho d to the class Shap e e ectively provides this assurance, even

when the metho d in class Shap e is never actually executed.

12.6 Pure Polymorphism

Many authors reserve the term polymorphism or purepolymorphism for situations where

one function can b e used with avarietyof arguments, and the term overloading for situ-

ations where there are multiple functions all de ned with a single name. Such facilities

are not restricted to ob ject-oriented languages. In Lisp or ML, for example, it is easy to

write functions that manipulate lists of arbitrary elements; such functions are p olymorphic,

b ecause the typ e of the argument is not known at the time the function is de ned. The abil-

ity to form p olymorphic functions is one of the most p owerful techniques in ob ject-oriented

programming. It p ermits co de to b e written once, at a high level of abstraction, and to b e

tailored as necessary to t avariety of situations. Usually, the programmer accomplishes

this tailoring by sending further messages to the receiver for the metho d. These subsequent

messages often are not asso ciated with the class at the level of the p olymorphic metho d,

but rather are deferred metho ds de ned in the lower classes.

An example will help us to illustrate this concept. As we noted in Chapter 8, the class

Numb er is an abstract class, parent to the wrapp er classes such as Integer, Double, Float.

The de nition of the class is similar to the following:

public abstract class Number f

public abstract int intValue;

public abstract long longValue;

public abstract float floatValue;

public abstract double doubleValue;

The extreme cases may b e easy to recognize, but discovering the line that separates overloading from

p olymorphism can b e dicult. In b oth Java and ML a programmer can de ne a numb er of functions, each

having the same name, but which take di erent arguments. Is it overloading in Java b ecause the various

functions sharing the same name are not de ned in one lo cation, whereas in ML-style p olymorphism they

must all b e bundled together under a single heading?

12.7. EFFICIENCY AND POLYMORPHISM 215

public byte byteValue

f return byte intValue; g

public short shortValue

f return short intValue; g

The metho d intValue is abstract and deferred{eachtyp e of number must provide their

own implementation of this metho d. The metho d byteValue, on the other hand, is not

overridden. It is a purely p olymorphic algorithm. Regardless of whether the receiver is an

integer, a double precision oating p oint value, or some other typeofnumb er, this is the

only de nition that will b e found. For all of these di erenttyp es, when byteValue is invoked

this will b e the algorithm that is executed.

The imp ortant de ning characteristic of pure p olymorphism, as opp osed to overloading

and overriding, is that there is one function with the given name, used with a variety of

di erent arguments. Almost always, as in this case, the b o dy of such an algorithm will make

use of other forms of p olymorphism, such as the invo cation of abstract functions shown here.

12.7 Eciency and Polymorphism

An essential p oint to note is that programming always involves compromises. In particular,

programming with p olymorphism involves compromises b etween ease of development and

use, readability, and eciency. In large part, eciency has b een already considered and

dismissed; however, it would b e remiss not to admit that it is an issue, however slight.

A function, such as the byteValue metho d describ ed in the last section, that do es not

know the typ e of its arguments can seldom be as ecient as a function that has more

complete information. Nevertheless, the advantages of rapid development and consistent

application b ehavior and the p ossibilities of co de reuse usually more than make up for any

small losses in eciency.

12.8 Chapter Summary

Polymorphism is an umbrella term that is used to describ e a variety of di erent mechanisms

found in programming languages. In ob ject-oriented languages the most imp ortant forms of

p olymorphism are tied to the p olymorphic variable{a variable that can hold many di erent

typ es of values. For example, overloading o ccurs when two or more functions share the same

name. If these functions happ en to b e found in classes that have a parent class/child class

relationship, then it is called overriding. If an overridden function is used with a p olymorphic

variable, then the particular function executed will b e determined by the run-time value of

the variable, not the compile-time declaration for the variable.

216 CHAPTER 12. POLYMORPHISM

Other forms of p olymorphism include overloading from indep endent classes, parameteric

overloading overloading that is disambiguated by the typ es of arguments used in a function

call, and abstract metho ds.

Note that the use of p olymorphism tends to optimize program development time and

reliability, at the cost of run-time eciency. For most programs, the b ene ts far exceed the

costs.