Relevant Logic

OOP Book extract: Polymorphism

This is an extract from our book, Object Oriented Programming with REALbasic (forthcoming)

Polymorphism: Purpose and Roles

The more interesting thing we can do using OOP is to radically alter the way the parts of this project relate to each other. At the moment, all the code to connect the various parts of our project together is outside of those parts themselves.

OOP gives us a new way to approach both sides of the connecting-things-up problem:

1. Writing the logic for the individual parts (counting words, reading from the clipboard, and so on); and

2. Connecting these different parts together.

The class handles both of these tasks. A given class will have (up to) two aspects to it:

1. Parts that let it do whatever it needs to do (let's call that the class's purpose), written entirely in the class's own idiosyncratic terms; and

2. Parts that let it play the role it needs to in other parts of the program (let's call this its roles), fitting into those other parts' idiosyncratic terms.

This lets us draw a picture:

In Figure 3, the class Foo has a purpose (represented by the cogs). To perform whatever tasks constitute its purpose, it needs to connect to one or more Bar objects (the arrows on the left). These calls are exactly and only what Foo needs for its purpose. Other classes, in performing their tasks, will occasionally require a Foo to play the role of a Tar or a Dar object (the smaller groups of arrows on the right). A Foo can also be treated as just a Foo (which means every call into the class-all of the arrows on the right-are available).

Let's look at how this idea works in our example program.

Using OOP, the connecting-up of the code that formerly occurred in the Select Case statements is now almost entirely inside a set of classes we define to represent the sources, the processes and the displays. The result is that our OK button action handler will now look something like:

In this code, an object is associated (via the ListBox.CellTag property) with each row of the three ListBoxes. We just pull the CellTags out for the selected rows (casting them to the appropriate type as we go, because CellTag returns a Variant), and ask them to sort out what they need to do with each other. We ask the process to do its thing with the source of text, and then we ask the display to do its thing with the process. All the details of making them work with each other is now inside of the classes.

By the way: the thing that's really bizarre when you first encounter polymorphism is that the big Select... Case... statement hasn't just moved-it's gone. You won't find an equivalent of it anywhere in the program.

Good OOP code will usually mean a lot less If... Then... and Select... Case... statements. Sounds impossible, but watch: there is in fact nothing up our sleeves.

To make that OK button's code work, we define types (notice we don't say "classes") called TextSource, TextProcessor and ProcessDisplayer, and then set up our classes so that they assume the role of TextSources, TextProcessors or ProcessDisplayers. This lets them all work together without needing to know any more details than necessary about each other.

For example, the purpose of any TextProcessor can be written entirely in terms of the external features (the Public Method calls and Properties) common to all TextSources. This lets us add any number of wildly different TextSources, and as long as they all provide equivalent external features, they will all work with all the TextProcessors.

Let's look at how we actually use polymorphism to simplify our example program.