Computer Science Educators Stack Exchange is a question and answer site for those involved in the field of teaching Computer Science. It only takes a minute to sign up.
Sign up to join this community
I am preparing a lesson about polymorphism in C++ and I would like to give an original example other than animals and shapes and I am really struggling with it because I realize polymorphism is not that useful for real concrete applications.
Can someone suggest a good example of polymorphism use?
Let me give some background that will, I hope, change a few minds about polymorphism and how it should be used and when its use should be avoided. The essence of it is that too many of the examples are naive and incorrect. They may serve as metaphors, but are, in practice, unworkable. Let me try to show why and also show how polymorphism can be extremely useful - even essential in OO style programming.
One of the problems is that most OO languages permit things to be built in a way that they should not be built. That isn't special to OO, of course. You can write 20 page functions with if and while statements nested 15 deep in C, of course, though no one can understand or maintain the code. Likewise you can use concrete subclassing in a way that builds equally mis-formed software. One of the first examples of subclassing to appear in print was that a Circle class was a subclass of a Point class. It was done this way because it was easy to do, not because it was sensible. A circle isn't a special kind of point. But to build the Circle class from a Point class you could just add a single field for the radius and use the point coordinates for the center. But it makes no sense.
First, the Animal hierarchy is unsuitable teaching students about polymorphism unless you remember that the entire hierarchy consists of abstractions, not concrete "objects". There are no instantiations of class Mammal, or Vertebrate. Those are merely abstractions. There are Kangaroos, of course, but there are no subclasses of Kangaroo, unless Kangaroo itself is an abstraction.
Likewise Vehicle is a poor vehicle (heh heh) for teaching polymorphism as there are too many variations in the concrete things that carry that description. A bicycle, a golf cart, an automobile, and a tractor-trailer rig are all Vehicles. So is a Sherman Tank. They have very little in common other than mobility and the capability of carrying things. If you try to build a "hierarchy" of such things, the variations will overwhelm the commonalities. They are more "unlike" than they are "like", in fact. Just as for Animal.
The problem, as I see it, is that people try to give examples that are "too big". Top-level design with polymorphism. This is hard to manage and usually fails. In fact, one of my rules for building good software is that any concrete hierarchy that needs to add publicly visible elements in subclasses is fundamentally broken. Why is that?
In building good software we need to manage complexity. Complexity is what kills us. It makes our programs buggy if not well managed and it also makes them hard to maintain. Suppose that you are at a point in a program in which you, the programmer, have built a structure that required ten thousand decisions to be made and the software didn't hide any of them from you at the current line you are writing. You need to take account of every decision that has been made. It is impossible. It is nearly impossible to maintain more than about seven independent items in your mind. Software is intended, actually, to hide such decisions. It is why that 15 level selection structure is impossible to maintain. Polymorphism is a way to manage complexity if used well, but since it can be used badly it can also add to the complexity burden. So, you need a way to use it well and to teach good usage.
For example, suppose that I have, in Java, a List of Vehicles. Suppose that Vehicle is a superclass and that every subclass of Vehicle has added different public features. The bicycle and tractor-trailer classes know about number of gears, but it is irrelevant for golf carts. All is well until we try to remove items from the List and operate on them. All the program knows about them is that they are vehicles unless either (a) we remember the most specific class of each item externally (mentally) or (b) we provide a way for the program to recapture the most specific class. Since (a) is essentially impossible, Java provides for (b), of course. But having to ask instanceof questions or do some sort of class based switch means that we have completely given up the advantages of polymorphism. We need to recapture the most specific thing when polymorphism is supposed to let us deal with general things. You are back to writing if statements when they shouldn't be needed (if you had done a better job).
Suppose that instead of thinking of using polymorphism at a large scale, think of it at a much smaller scale. Don't try to get some polymorphic sense about vehicle overall, but think about how vehicles are actually built in the real world. I'll take bicycle as a simple example.
I have a lot of bicycles, actually. I have a nice one that is suitable for trail riding and for expeditions and even for the road. How is that. The bike I'm thinking of is composed of parts. It has a seat, wheels, gears, etc. I'll focus on just those. When I first purchased it the bike was set up primarily for moderately comfortable use on mild trails. It worked well for that. But the parts I mentioned are all replaceable. By changing the saddle I can make it better fit my anatomy. By changing the wheels I can make it much nicer on the road - both lighter and with a smoother ride. By changing the gears - even the number of gears I can make it more useful for serious rocky trails or for more modest prepared surfaces. This is polymorphism used well. I can easily swap parts and by giving it one part at one time and a different part at another time I can give it different behavior. It is the behavior that is polymorphic, not the interface. The two sets of wheels I have for this bike are interchangeable, but behave very differently. The saddles enable one use or another, for one rider or another. But the interface between the saddle and the rest of the bike is fixed. And I don't need to remember each time I switch gears whether I have the road wheels or the trail wheels on the bike. It "works" the same, but "behaves" differently without any decisions (if-this-then-that) on my part as I ride. The only time I need to make decisions is when I set up the bike for a ride (or an expedition) and then the bike itself "remembers" all of those decisions and behaves appropriately. I don't have to remember whether I'm on the "expedition bike" or the "fast road" bike. Nor do I have to recapture that knowledge at any point in my ride.
You can build software this way also. Build complex objects with composition - lots of part. Put the polymorphism in the parts. Each kind of part has an interface that doesn't need to be tailored to use (i.e. no added public features in subclasses). When the object of which these polymorphic things are a part needs to change its behavior, swap out one part for another. The overall object's interface didn't change, but its behavior does.
For example, in a Calculator, sometimes pressing the "five" key does one thing (accumulates into the current display value) and sometimes does something different (begins the next value in the computation after an operator key). You can use different objects to handle these two things. The calculator either has an accumulator object or an initiation object attached to the five key. The objects are swapped at appropriate times, but once the object is swapped the calculator itself has different behavior. But, the key idea, is that the accumulator object and the initiation object have exactly the same interface. This means that I, the programmer, don't need to remember which it is, the calculator remembers that, and I the programmer don't need to recapture the specific class of the object attached to the numeric key since I interact with both of them (as a programmer) in exactly the same way.
This is true polymorphism. Other ways of using it are very ad-hoc and require external complexity management that is better handled by the software itself.
This is how automobiles are built these days. You can buy most cars with different engines, different seats, different entertainment systems, etc. But each of those various engines presents the same interface to the rest of the automobile. Therefore they are swappable without modifying the chassis, and by swapping them they change the behavior of the object of which they are a part.
Let me add a simple rule of thumb for OO programmers who might benefit from the guidance.
Think of every addition you make to the public interface of a concrete subclass (even when implementing an interface) as a failure. It is sometimes necessary to do it and even the libraries show evidence of it, but think of every new public feature (in a concrete class) as a failure of design. You are building in the necessity to do ad-hoc decision making in the future. You can probably avoid that by rethinking the design. Every ad-hoc decision you don't need to make in the original build and especially in maintenance is a BIG WIN.
Say you want to present a choice of interactive games
out.println("Which game (...) ?");
Game game;
switch (in.nextLine()) {
case "HI-LO" :
game = new HighLowGame();
break;
case "Riddle" :
game = new RiddleGame();
break;
...
}
Here you are. You have polymorphism. The game variable may refer to objects of different types.
Now, how to play a game (in textual form) ?
out.println(game.getPresentation());
while(! game.isOver()) {
out.println(game.getQuestion());
out.print("> ");
game.submitAnswer(in.nextLine());
out.println(game.getMessage());
}
Polymorphic code. Now what is in a Game?
interface Game {
String getPresentation();
boolean isOver();
String getQuestion();
void submitAnswer(String line);
String getMessage();
}
An implementation ?
class RiddleGame implements Game {
String getPresentation() {
return "What cheese is made backwards?";
}
String getQuestion() {
return "Guess it!";
}
boolean found = false;
void submitAnswer(String line) {
found = line.trim().equals("edam");
}
boolean isOver() {
return found;
}
String getMessage() {
return found ? "you got it:" : "no, it isnt";
}
}
Boring java details omitted.
[rant] Most introductory examples for OOP are utterly silly and totally inadequate to explain that classes are here to offer services. This unfortunate fact leads them to a lot of misconceptions. [/rant]
The purpose of OOP is NOT to build taxonomies of animals, or make container objects with a getter and a setter for each attribute. It is not to model even a simplified view of the real world. It is there to write code which does something.
Oh, well, I see you don't like the RiddeGame because it knows only one joke. So introduce a RiddleProvider as a parameter, whose job is to supply a Riddle (question + answer pair).
You can imagine several kinds of RiddleProviders, so it is itself an interface with different implementations.
The simplest is the AlwaysTheSameRiddleProvider, which only know one joke, just like me. Others can run a predefined sequence, or a random choice, from an array, or from a file. Again, they offer a service to be used by another object.
Almost any popular library such as Boost will have tons and tons of code with polymorphism examples. For instance, look at Polymorphism models write up in Boost. I'm sure, you used them a lot too, e.g. iterators in containers, streams and so on. They're extremely practical
One of the most used examples of polymorphism in real code would be sort. You don't write a comparison sort method for each type of object: you write one comparison sort method and then either implement a comparator for the type or make your objects implement a Comparable interface.
I hope this example convinces you to change your opinion that "polymorphism is not that useful for real concrete applications".
Bearing in mind that the only good analogy or example or metaphor of a computer thing is the computer thing, because computer things are not really like anything else (or they would just be that thing anyway):
I created an example for my students using a Tic Tac Toe game, which can be played by a human against the computer, or having it play many games against itself and tally the results. I created 5 strategies, each built on the one simpler than it, as follows
I was able to explain how the strategies are based on a simpler one and add some capability. The 'Tournament' feature played each strategy against all others 10,000 times and showed the results. It was very convincing. So, games might be a good realm to explain.
As a professional software engineer, I used polymorphism all of the time. Here are a few examples.
I well designed system can use inheritance all over the place. But can also be over used.
Note there are many ways to do polymorphism, including:
#include (arrange for different files to be included).