Object Oriented Programming Philosophy

Part 4 -- Virtual Functions and Polymorphism




Welcome

Hi! I hope that you are eager to continue this OOP chapter. Polymorphism and virtual functions are among the most important concepts in OOP. I hope that you do grasp these firmly after reading this chapter. Without further ado, let's go to the stuff.

 

Polymorphism and Virtual Functions

What is polymorphism? As you may guess: It means "many forms". What is it exactly then? To answer this question, let's imagine that we are going to develop a graphic libraries that can draw rectangles, triangles, and circles using OOP technique. You quickly notice that those three are of one common parent object, let's call it Shape2D. For each shapes, we define various capabilities. Of course, we then put the common capabilities into the parent. Those capabilities are coded inside methods in parent object. Then, we inherit those common methods and override them for each shapes since rectangles behave differently from triangles and circles. Those common capabilities are further translated down into specific child objects. Let's say one of those is the method Draw.

Thus, when we pass on an object to a method that takes a Shape2D parameter, wouldn't it be nice if we can invoke the method Draw and the correct Draw method is invoked without being explicitly examine that parameter whether it is a rectangle, triangle, or circle.

Let's consider the following snippet:

   procedure myProc(x : Shape2D);
   begin
      :
      :
      x.draw;
      :
      :
   end;

We want myProc invokes the correct draw method without explicitly examine whether x is a rectangle, triangle, or circle. In other words, whether we call myProc(someRectangle); or myProc(someTriangle); or myProc(someCircle);, it will always work without specifically detecting x.

This ability is called polymorphism. How is it possible? When we invoke x.draw, isn't that Shape2D's Draw method that is going to be invoked. Yes, you're right. However, if we define the Draw method in Shape2D to be virtual, x.draw will no longer refer to Shape2D's but rather its children's. Of course, this will depend on which instance you pass as the parameter, i.e. if you pass a rectangle, then rectangle's Draw method is going to be invoked, and so on.

So, in order to have the polymorphism concept work, the common methods in the parent object have to be defined as virtual functions so that it's corresponding children method is going to be invoked.

How can we define a method as virtual? Just put the virtual keyword after its declaration as follows:

     : { Inside object declaration }
          procedure myProc; virtual;

Then, you MAY NOT define its body. You just make it empty (or display an error message) as follows:

procedure myClass.myProc; { Note that the virtual keyword is gone here }
begin
  writeln('You should not call me!');
end;

Simple, right? Well, in the real OOP compiler, we are not allowed to define virtual function's body. I'm just confused that Borland Pascal complains the other way.

 

Abstract Classes

Class that contains virtual functions are called abstract classes. You should not instantiate abstract classes. In other words, don't new it to create an instance. Why? Because its virtual methods are not supposed to be called. Actually, the real OOP compiler should complain if an abstract classes is instantiated.

Abstract classes must have children classes. All of their virtual functions have to be inherited and overrided in the children classes. If not all of the virtual functions are inherited and overrided in a particular child class, then that child class will also be called an abstract class. If that's the case, that particular child class should be then be inherited by some other grandchildren classes.

 

Closing

This is the last of four articles covering OOP philosophies. These are not exactly THE OOP philosophies, but I'd rather say the OOP features supported by Borland Pascal. However, the features covered here, fortunately, the key features of OOP. I should say that Java offer a more brilliant OOP features. If you're interested on OOP, you should leer on Java.

Building programs based on OOP techniques are very difficult at first. It may require "brainwashing" :-). Just kidding. Somehow, that's true since your old paradigm has to be overhauled to fit into a totally new idea. This can be daunting at first. However, I should say doing things at first are always difficult. So, I suggest you to keep trying and don't give up.

The next chapters would be an example on how to build components and applications using OOP method. I hope this will help you out. Bye for now!

 


Where to go

Chapter 5
News Page
Pascal Lesson 3 index
Contacting Me


Roby Joehanes © 2001