The object-oriented paradigm has three defining characteristics: encapsulation, inheritance, and polymorphism. While encapsulation and inheritance can stand independently, polymorphism requires inheritance, which is only possible in those systems that also support inheritance. Although polymorphism is a potent tool, it isn't easy to fully appreciate its power outside large, complex programs. Therefore, this semester focuses on the syntax and the behavior of polymorphic systems while forgoing more useful examples. Rest assured that subsequent courses will build on this basic foundation.
Chapter 12 covers several topics, but they all lead up to and revolve around one central theme: polymorphism. Stated without detail, polymorphism is just a way of choosing which function to execute when multiple functions match a function call. Remarkably, it permits us to delay choosing which function to call until the moment of the call itself! You may be asking yourself, "Why wouldn't I know which function to call?" Let's set the stage by posing a problem and outlining a solution that doesn't use polymorphism. Later, we'll revisit the problem and see how a polymorphic solution can simplify the program.
Our proposed program must perform three tasks:
class Circle
{
public:
void draw();
};
|
class Rectangle
{
public:
void draw();
};
|
class Triangle
{
public:
void draw();
};
|
cout << "C:\tCircle" << endl;
cout << "R:\tRectangle" << endl;
cout << "T:\tTriangle" << endl;
cout << "Please choose a shape: ";
char choice;
cin >> choice;
cin.ignore();
Circle* c = nullptr;
Rectangle* r = nullptr;
Triangle* t = nullptr;
switch (choice)
{
case 'C' :
case 'c' :
c = new Circle(...);
break;
case 'R' :
case 'r' :
r = new Rectangle(...);
break;
case 'T' :
case 't' :
t = new Triangle(...);
break;
}
switch (choice)
{
case 'C' :
case 'c' :
c->draw();
break;
case 'R' :
case 'r' :
r->draw();
break;
case 'T' :
case 't' :
t->draw();
break;
}
Complete demonstration program: shape-proc.cpp
Figure 3 provides at least a partial answer to the question, "Why wouldn't I know which function to call?" The programmer doesn't know which function to call until the user selects a shape, which only happens after the program starts running. So the program must be sufficiently dynamic to select the correct draw function from several possible choices while running. Our current program seems to do this well enough.
But suppose that the user wishes to add another shape to the program: an Ellipse. What code must we modify?
Steps 1 and 2 are inescapable regardless of how we write the code. Fortunately, both steps are localized - each step requires editing code in one place in one file. In this simplified example, step 3 seems on par with the first two, but this is not the case. The switch statement illustrated in step 3 illustrates using the object once. An authentic program must repeat the switch statement whenever and wherever the program uses the user's shape. Furthermore, classes in a real program typically have many functions making their objects more complex and used many times throughout a program. Each time a function is called in an actual program, a code block similar to Figure 3 is necessary. This code structure is bulky and cumbersome, even without modifying the program.
Now imagine that our program consists of scores of files, with each file consisting of hundreds or thousands of lines of code, which is a common situation in "real world" programs. When we modify such a program, there is a real risk that some instances of the Figure-3-like code will be overlooked and not updated, which may introduce a bug that might not be detected until a catastrophic failure occurs. The problem represented by Figure 3 arises from the practice of binding a function call to a specific function too early at compile time.
Normally, when the compiler processes a function, it generates the machine code corresponding to the function body. The operating system loads the function's machine instructions into memory with the rest of the program when it runs. The compiler binds the call to that location in memory for each function call. That is, the compiler generates instructions to jump to that location in memory, execute the function's instructions, and then return to the calling point. The compiler creates the binding when it identifies the address of a function and generates the instructions needed to jump to that address. So, for the function calls
c->draw();r->draw();t->draw();These terms are synonyms with the same meaning: the compiler can bind a function call to a specific set of machine instructions when it compiles the program. Compile time-binding works most of the time - all the functions we have written this semester are processed this way. But as Figure 3 demonstrates, compile-time binding doesn't always work and is sometimes inconvenient. Polymorphism allows us to write more elegant code that is easier to maintain.
Polymorphism is active by default in Java programs, and programmers must explicitly deactivate it when it's not wanted. Conversely, before programmers can use polymorphism in a C++ program, they must activate it by satisfying five requirements. We have previously explored some of those requirements, but others are new, and we'll explore them in greater detail in subsequent sections.
These required features roughly outline the remainder of the chapter.
The terms overloading and overriding are similar and therefore easily confused. Let's take a moment and review their similarities and their differences. You might find it worthwhile to review Figure 2 where the terms were first introduced.
| Overloaded Functions | Overridden Functions |
|---|---|
|
|
Although polymorphism requires a function override, programs may override functions without making them polymorphic.