Polymorphism: As It Is Played

Polymorphism Book Cover

ISBN: 978-1940113050

This small book will teach you about how to effectively program with polymorphism. It follows a hypothetical conversation of two students as they build a small application using only dynamic polymorphism.

Additiionally, it shows how Pair Programming and Test First Development work in the piecemeal creation of an interesting program. There is also a bit about Design Patterns, especially the Strategy Pattern.

Advice is also given to educators about project creation for students so that the beginning student can work on interesting problems without getting lost in details of design best left until later.

There are a few exercises to help solidify the ideas and some additional readings.

There is a second book: Polymorphism Companion. It discusses some of the ideas of Polymorphism: As It Is Played at a deeper level.

Note that some of this material has appeared earlier in a different form in Beyond Karel J Robot by the same author.

Introduction

This little book weaves together a few themes that should be known by every programmer that uses an Object-Oriented language such as Java or Python. The main theme is Polymorphism, which gives the programmer a clean way to program alternative actions in a program. The main idea is that a fragment of code should do exactly one thing in a simple way.

A second theme is building applications using Piecemeal Growth, rather than overall implementation of a predefined design. A program grows organically, and the needs may change over the course of development. This means that the program built is what its sponsor wanted at the end of development, which may be different from the perceived needs at the start.

We also show how to use two important tools, Eclipse and JUnit, to implement a program using Test Driven Development. This simple idea is profound. The programmer writes tests immediately before the code that is being tested. The names of program actions used in the tests then become the names of methods in the application. So, a certain low level of design is done in the test framework. An implication of this is that the first time the programmer sees and uses a name it is in an applied use, not its definition. Thus, you get a sense of what it will be like in use.

The vehicle for all of this is a hypothetical set of conversations between two students building a project for a professor. The students discuss their issues and decisions as they go along and develop the program one Story at a time. Each story introduces one desired feature of the result. In this project, the professor has sequenced the stories to relieve the students of problems of design.

This case study is not about building large things from independent parts. It gives a different view of Object-Orientation. Suppose that you have to build a single class that exhibits complex behavior. You want the code to be as simple as possible. But even if you are building a large program, you still need to build the individual classes. Perhaps like this...

Meta: Why a Book?

The reason that I wanted to present this material as a book is that the resulting code, a single class named CalculatorModel, isn't very enlightening when only the final version is seen. The code evolved into an organic whole. It has many parts, but it isn't obvious how they relate to each other unless you already understand polymorphic programming. Once you do, it becomes clear, but for those whose only tool is an IF statement the result seems to be overkill. Simply explaining the parts would be very unsatisfying until you grok it as a whole.

If you examine a living thing in detail, the various parts may be obvious, but the interconnections less so: heart, liver, nerves... Those parts evolved over time in an integrated way rather than being assembled. You can't separate them from the organism and have them mean the same as when they were in place. The life force in the organism is a consequence of the parts and their interconnections but it is even less clear how that life force arises.

In a way, polymorphic programming is like that. Notice that the earlier versions of many of the methods in CalculatorModel are very unlike the final versions. They evolved to meet a new environment: the introduction of a new feature via a story. The tests provide a fitness measure of the current version of the application.

The program evolved, and so for you to understand the final result you need to see the process as it unfolds. So, we follow two students as they develop the program, looking over their shoulders at the various versions and learning why they built them as they did.

July 2, 2023

Contents:

Introduction

Meta: Why a Book?