Chapter 5: Understanding Polymorphism
Overview
The Previous Chapters Covered two of the three features of object-oriented programming languages. In review, encapsulation is the hiding of functionality (implementation details) inside classes. This allows the developer to separate distinct parts of code so those parts can’t interact with each other at all (or can interact with each other only in ways the developer can control via the public interface of the class). By achieving this separation, the developer assures that changes to one part of the code won’t produce undesired side effects in another part.The second object-oriented feature is inheritance, which is the ability to create a class by basing it on some other class. This allows the developer to extend or change the functionality of an existing class without having to duplicate the code for all the existing functionality.This chapter discusses the third feature of object-oriented programming: polymorphism. This rather imposing word means that different classes can provide similar functionality to the outside world but through different (possibly very different) implementations.For example, real-world objects behave in a polymorphic manner. Suppose you’re throwing a party and five people at your workplace ask you for directions to your house. You give the same directions to all five people: “From the office, go south on Main Street for three blocks. Turn right on Maple. At the first stop sign, turn right again on Evergreen. My house is the fifth on the left, 1234 Evergreen.”If you think of the five people as instances of some imaginary Person class (or some subclass of Person), you can consider that you’ve invoked each person’s Travel method, which takes as a parameter a TravelDirections object. This object is the object-oriented version of the directions given (ignore how one might implement such an object for the moment).What you haven’t considered in calling each person’s Travel method is exactly how each person plans to travel to your party using the directions given. The following items represent how each person might come to your party:
Person 1 drives her car from work to your house.
Person 2 drives home first to change, then takes a cab to your party so he doesn’t have to worry about driving home if he has a few drinks.
Person 3 hitches a ride with Person 1.
Person 4 walks to your house from work and plans to have her roommate, who is also coming to the party, drive her home.
Person 5 takes his nifty new Segway personal transport device from work to your house.
Even though you’re the host of the party, it isn’t your responsibility to understand how each person is going to get to your house. Instead, you merely invoke each person’s Travel method with the proper parameters (the directions and perhaps the time to show up), and each person decides on the best way to perform the task asked of them (to show up to the party).Polymorphism in an object-oriented programming language works the same way. You can invoke a method on a class without knowing (or caring) how the class gets the job done so long as the job does indeed get done.