| Author Name |
Status |
Posted Time |
| Jeida Kaali Menon |
|
2/9/2007 2:14:20 AM |
| Author is Offline |
Polymorphism in C++
Polymorphism is in short the ability to call different functions by j
ust using one type of function call. It is a lot useful since it can group classes and their fu
nctions together. It is the most important part of Object-Oriented Programming. Polymorphism is
the core of object-oriented programming .C++ supports polymorphism by allowing member function
s defined in classes to be overridden with member functions having the same names, but differen
t implementations, in derived classes. In selecting the appropriate member function to call in
response to a function invocation, C++ distinguishes between the static type of a reference and
the dynamic type of the object it refers to at a given point. The dynamic type must be a desce
ndant of the static type The invocation is type-checked based on the static type of the referen
ce. If the function called is a virtual member function, the member function associated with th
e actual object pointed to is called dynamically at run time. If the function is non-virtual, t
he call will have been statically bound to the member function of the reference's class at comp
ile time.
Polymorphism allows an entity (for example, variable, function or object) to take
a variety of representations. Therefore we have to distinguish different types of polymorphism
which will be outlined here.
The first type is similar to the concept of dynamic binding. H
ere, the type of a variable depends on its content. Thus, its type depends on the content at a
specific time:
Code:
v := 123
/* v is integer */
...
/* use v as
integer */
v := 'abc'
/* v "switches" to string */
...
/* use v as stri
ng */Another type of polymorphism can be defined for functions. For example, suppose you want t
o define a function isNull() which returns TRUE if its argument is 0 (zero) and FALSE otherwise
.
For integer numbers this is easy:
Code:
boolean isNull(int a)
{
if (a == 0)
then
return TRUE
else
return FALSE
endif
}
However, if we want to ch
eck this for real numbers, we should use another comparison due to the precision problem:
Code:
boolean isNull(real x)
{
if (x < 0.01 and x > -0.99) then
return TRUE
else
return FALSE
endif
}
In both cases we want the function to have the name i
sNull. In programming languages without polymorphism for functions we cannot declare these two
functions because the name isNull would be doubly defined. Without polymorphism for functions,
doubly defined names would be ambiguous. However, if the language would take the parameters of
the function into account it would work.
Thus, functions (or methods) are uniquely identifi
ed by:
• the name and
• the types of its parameter list.
Since the parameter list of bot
h isNull functions differ, the compiler is able to figure out the correct function call by usin
g the actual types of the arguments:
Code:
var a : integer
var x : real
a =
0
x = 0.0
...
if (isNull(a)) then ... /* Use isNull(int) */
...
if (isNull
(x)) then ... /* Use isNull(real) */If a function (or method) is defined by the combination o
f
• its name and
• the list of types of its parameters
we can say polymorphism. This typ
e of polymorphism allows us to reuse the same name for functions (or methods) as long as the pa
rameter list differs. Sometimes this type of polymorphism is called overloading.
The last t
ype of polymorphism allows an object to choose correct methods. Consider the function move() ag
ain, which takes an object of class Point as its argument. We have used this function with any
object of derived classes, because the is-a relation holds.
Now consider a function display(
) which should be used to display drawable objects. The declaration of this function might look
like this:
Code:
display(DrawableObject o)
{
...
o.print()
...
}
We
would like to use this function with objects of classes derived from DrawableObject:
Circle ac
ircle
Point apoint
Rectangle arectangle
display(apoint) /* Should invoke apoint.print() */
display(acircle) /* Should invoke acircle.print() */
display(arectangle) /* Should invoke ar
ectangle.print() */
The actual method should be defined by the content of the object o of fu
nction display().
Since this is somewhat complicated, here is a more abstract example:
Code:
class Base
{
attributes:
methods:
virtual f ()
funy()
}
cl
ass Derived inherits from Base
{
attributes:
methods:
virtual funx ()
funy()
}
demo(Base o)
{
o.funx ()
o.funy()
}
Base abase
Derived aderived
demo(abase)
demo(aderived)In this example we define two classes Base and Derived. Each cl
ass defines two methods funx() and funy(). The first method is defined as virtual. This means t
hat if this method is invoked its definition should be evaluated by the content of the object.
We then define a function demo() which takes a Base object as its argument. Consequently, we
can use this function with objects of class Derived as the is-a relation holds. We call this f
unction with a Base object and a Derived object, respectively.
Suppose, that funx() and funy
() are defined to just print out their name and the class in which they are defined.
Then t
he output is as follows:
funx() of Base called.
funy() of Base called.
funx() of Derived cal
led.
funy() of Base called.
The first call to demo() uses a Base object. Thus, the function
's argument is ``filled'' with an object of class Base. When it is time to invoke method funx()
it's actual functionality is chosen based on the current content of the corresponding object o
. This time, it is a Base object. Consequently, funx() as defined in class Base is called.
T
he call to funy() is not subject to this content resolution. It is not marked as virtual. Conse
quently, funy() is called in the scope of class Base.
The second call to demo() takes a Deri
ved object as its argument. Thus, the argument o is filled with a Derived object. However, o it
self just represents the Base part of the provided object aderived.
Now, the call to funx()
is evaluated by examining the content of o, hence, it is called within the scope of Derived. On
the other hand, funy() is still evaluated within the scope of Base. 
|
