concept of polymorphism

I am slowly understanding more about Polymorphism in obj-oriented terms. I will try to illustrate it as I interpret; please tell me if my points are correct about the subject:

the ability to name identical methods that perform different things.
ex1: when an object/class has several methods with the same name that take different parameters:
Calculate(int a), Calculate(int a, int b), Calculate(string direction)
ex2: classes WINDOW and DOOR both have open() and close() methods -- they are named the same but perform duties in different manners
ex3: in VB.NET, the msgbox() method takes different paramters -- you may only include a msg, or you can give additional
settings such as bar title and Buttons included. This is possible because the class library must have done it this way:

msgbox(string msg) 'First form
msgbox(string msg, DialogResult buttons) 'Second form
msgbox(string msg, DialogResult buttons, string title) 'third form

Depending on which parameters you pass, the appropriate method will execute.

Hi
It's correct all you write about polymorphism.......

I thought polymorphism is where you inherit properties from more then one class.

ie: my "myBigNum" class may inherit from the "string", "integer", and "math" classes I wrote.

What you describe sounds like simple method/operator overloading. But I may be wrong. I use a lot of techniques I don't know the names of.

Example 2 best describes polymorphism in OO terms, the other two might refer to other forms of polymorphism but I think they are usually referred to as "name overloading" or something like that. Foldoc describes different types of polymorphism, including 'OO polymorphism', but it might be confusing so here's a longer explanation of what polymorphism is in terms of objects.

In OO, polymorphism is the ability to call a method of an object without knowing precisely what object you have. All you know is what the method looks like - i.e. it's name and parameters - and that the object will have that method; essentially the object is an instance of a class which belongs to a family of related classes (typically through inheritance). The 'correct method' to call is resolved at runtime, not compile time.

Here is some OCaml code declaring some classes which don't do anything terribly useful but serve to highlight polymorphism in OO terms.



And here is simple program using the above classes to illustrate polymorphism



The above program will print the results of calling the do_something method on two objects...



The perform_action function doesn't know anything about sub_one or sub_two classes, it only knows about base_class. Since both sub_one and sub_two inherit from base_class they can be used where an object of type base_class can and the runtime system will figure out the right version of the method to call.


HTH,
C

p.s. For the curious, OCaml has both parametric polymorphism and OO polymorphism and can combine both to provide interesting reuse capabilities.

edit: oops! forgot the results of the program...

Hi aragon. One confusion - you say that we can call a method of an object without knowing precisely what object you have, but in the illustration we see that s1 is an obj of the Sub_One class, right?

Yes that's correct. We know what object we have by looking at the code, but this is a very simple example. I was referring to code like perform_action which is written so that it doesn't know exactly what object it has. It expects a parameter of type base_class and calls a method as if it were an object of type base_class. It doesn't know that the parameter is actually a sub_one or sub_two at compile time because it doesn't know these classes even exist. The code is the same for all classes inheriting from base_class.

In essence you can think of base_class as defining a family of classes. perform_action knows that it can call the methods of any member of this family without knowing where in the tree the member is. The runtime system works out that it's a sub_one and calls that right code, but at compile time we (i.e. perform_action) don't know we have anything other than an object of type base_class. The point of this polymorphism is that we don't want to know exactly what type of object we have, only that it extends from base_class. This allows us to write code that works for all objects of the family, even objects that haven't been written or even concieved of yet.

Consider a drawing program with a number of primitive shapes. Let's say you have two types of shape, rectangles and circles. The process for drawing a rectangle is different from a circle so we need to have different code for each. We could write code like this...



but what happens if we suddenly discover we want to draw triangles? We could modify the code like this



Now what happens if we need to draw polygons, lines, etc? I haven't shown any parameters being passed to the code other than x, but you would need different parameters for each shape. 3 vertices/points for a triangle, 3 for a rectangle, 1 for a circle plus its' radius and you have to pass this info some how

A better way would be to write code that could work with all shapes. We can do this by creating a root class 'shape' with a draw method and have 'rectangle' and 'circle' classes provide the code to draw the shape... i.e. each type of shape knows how to draw itself. draw_shape disappears and we can extend the kinds of shapes the system can draw simply by extending the shape class and implementing the draw method. But the code that draws the entire scene doesn't change a bit and is simpler because it only knows about the shape class.

The higher level code will call the constructors on each object and provide the relevant parameters, but the guts of the system just deals with shapes.

I found this wikipidea link which describes polymorphism (with examples) better than foldoc.


C

Actually, the correct method to call is still usually determined at compile time. In the case of virtual functions, the binding is delayed until runtime if the pointer is to the base class and not a derivative. Polymorphism is as you define it, however....inheriting from multiple classes is just 'multiple inheritance.'

Aragon's explanation sounds similar to function pointers, but using classes instead.

ie:


I use this often when writting my own languages. The p-code is a byte representing the array number of the function to call. It's very fast. (the function grabs the params from memory relative to it's location (param1=mem[pc+1];))

BTW: I had that code on my HD to make sure a free C compiler I downloaded allowed function pointers. That's why the "printf"s, and no "cout"s.

1. Inclusion polymorphism is found in OO languages where it is combined with dynamic binding to allow a reference to a baseclass refer to subclass. When invoking methods on that reference the implementation found in the subclass is used. The referencing part is inc. polymorphism and the execution of the subclass method is dynamic binding.

2. Parametric polymorphism is found in functional languages, e.g. Haskell, Miranda and Standard ML. It means that a parameter can have an arbitrary type. This is _not_ the same as templates and such.

3. Ad-hoc polymorphism is just a weird name for overloading. MsgBox is just several overloaded functions with the same name. Doesn't really have anything to do with OO, but this feature is present in most OO languages.

In most cases you will use polymorphism when you have a class inherit the funciontality of another class but need some (but not all) of the functionality of the child to be different. This way you can simply override the methods that require different functionality, while leaving the rest the same as they were when inherited.

When I think of polymorphism I consider the following class declarations.


notice that all my pointers are of type C (the Base class) the next question is what do you think will be printed when I call print from my base class pointers ?


if you thought the out put would be "C Class C Class C Class" then you would be wrong. Its A Class B Class C Class. this clearly shows polymorphism

Although polymorphism is actually only the ability for a C* to refer to an A* or B* transparently. The call dispatching to the correct method is dynamic binding. Don't confuse them like all those crappy OO book authors...