1.4 Polymorphism

Polymorphism

Polymorphism is, along with encapsulation and inheritance, one of the fundamental forces behind object-oriented programming. The word polymorphism comes from the Greek words poly, which means multi, and morphos, which means form.
In the world of object-oriented programming, this means that one behavior can be implemented in multiple forms. Because we're talking about behavior, this applies for methods. In plain English, polymorphism means that different objects have methods with the same name but they do different things or do equivalent things in a different manner. An example would be a rectangle's draw method that would do something very similar to the draw method of a circle the act of drawing is similar, but the implementation is very different.

When might this be helpful? Well, consider the movie theater example again. Every screen must have a method to turn lights on and off. This might be implemented like so:

DEFINE CLASS Screen AS Custom
FUNCTION TurnOnLights
** Some smart code goes here
ENDFUNC
ENDDEFINE

Of course we have more than just screens in our theater. We also have rooms such as the food counter, the hallways and the restrooms. They also have lights that must be turned on and off. Let's assume we have an object that turns on the lights in the whole building at 5:00 p.m. Of course, we don't want to implement a different set of messages for each room, so we create the same method in every class. Here is the code for these classes:

DEFINE CLASS Hallway AS Custom
FUNCTION TurnOnLights
** Some smart code goes here
ENDFUNC
ENDDEFINE

DEFINE CLASS Restroom AS Custom
FUNCTION TurnOnLights
** Some smart code goes here
ENDFUNC
ENDDEFINE

DEFINE CLASS FoodCourt AS Custom
FUNCTION TurnOnLights
** Some smart code goes here
ENDFUNC
ENDDEFINE

Assigning the same function name in every class becomes possible because methods belong to an object and can only be referenced by adding the object name. Otherwise the compiler might get confused.

Now, our light-handler object can simply turn on all the lights like so:

Hallway1.TurnOnLights()

Hallway2.TurnOnLights()

FoodCourt.TurnOnLights()

Screen1.TurnOnLights()

Screen2.TurnOnLights()

Screen3.TurnOnLights()

All we need to do is make sure that the light-handler object knows about all the rooms we have. I'll explain a generic way to do that later on when I talk about collections.

Another example is the File menu in standard Windows applications. Did you ever wonder how an application can possibly know which item to save when many different documents are open at the same time you click Save? Well, it actually doesn't know. It simply sends a "save" message to the currently active document. Each document might require a different action when it is saved. But the menu item doesn't care about that. It leaves all of this logic to the currently active object, which is completely responsible for saving its contents. The object must have a save method; otherwise, the message sent by the menu won't be received. (We'd get an error message because FoxPro wouldn't be able to find a receiver for the message.)

It might be a while before you can evaluate the power that polymorphism adds to Visual FoxPro, but it's well worth the effort to understand its power.