Introduction

This paper describes some of the patterns that occur in my sophomore-level Object-Oriented Programming course. You can find nearly all of these patterns documented in the patterns literature, though not always written at a level or in a form suitable for my students.

Context

I teach a course 810:053, Object-Oriented Programming, using Java. Students must complete our CS1/CS2 sequence before enrolling in 053, though currently nothing prevents students from waiting to take this course until much later. The goals of the course include having our students learn (1) how to do object-oriented design and programming and (2) a second programming language. In 053, I use Tim Budd's Understanding Object-Oriented Programming using Java as the primary text, with Arnold and Gosling's The Java Programming Language as a required reference.

Our CS1 and CS2 courses are taught in a fairly traditional way, using an Ada'83 subset of Ada'95 to introduce students to procedural programming, data abstraction, and encapsulation. Thus, I should not have to devote much, if any, time at all to matters of common syntax or to the mechanics of selection and repetition constructs. Students' understanding of data abstraction and encapsulation are weaker than I might otherwise hope.

I am teaching 053 for only the second time this semester, and so my ideas about the course and about the patterns therein are still inchoate. As a result, this paper is truly a work in progress.

The Patterns As They Appear

The following time line describes roughly the order in which we cover topics in 053 and roughly when students encounter which patterns.

• 1st and 2nd weeks

  We introduce the course, Java, and object-oriented design

• 3rd week

  We first get to "real" OOP, and these patterns arise immediately:

  • Object
  • Composed Method
  • Access Method
  • Functions for Loops

• 4th week

  I noticed the Java idiom Application Class.

• 5th week

  Students have now seen enough inheritance to work with:

  • Adapter
  • Subclass is Client

• 7th and 8th weeks

  As we explore inheritance in greater detail, I expose students to:

  • Substitution
  • Object Recursion

  Substitution recurs throughout the semester, especially when we delve into the idea of polymorphism (9th week forward) and when we work through a case study on the design of a payroll system (13th week).

  To give you an idea of what my students, I offer two sets of lecture slides that I used in class this semester. They will seem a bit incomplete, since we fill in many blanks during lecture, but should give you an idea of what we do:

  • introduction to substitution, beginning near the middle of the session

  • substitution and object recursion (thanks to Dwight Deugo for the idea of using a binary tree as a demonstration example)

  Remember that you are seeing these warts and all. Please be kind, and I welcome constructive suggestions!

• 9th week

  I introduce Decorator as a natural extension of Substitution. Here is the set of lecture notes that I used this semester (beginning with a page of notes that I made to myself after the session on how to improve the session for next semester).

• 10th and 11th weeks

  We study the Java AWT and Java's stream class hierarchy as rich sources of polymorphism. In these packages, we encounter the following patterns for the first time:

  • Strategy
  • Composite

  in addition to most of the others we have discussed previously.

• 11th and 12th weeks

  We cover Budd's chapter on design patterns and do a backward canvass for the patterns we have encountered earlier in the semester. To motivate the idea of design patterns more generally, I work through examples that demonstrate these patterns in Java:

  • Iterator
  • Abstract Factory

  I also try to relate the State pattern to substitution, though the ideas behind substitution are more important than the ideas behind state transitions.

  Last semester, I asked students to implements a simple four-function calculator in Java as a programming assignment. When we refactored a typical student solution, I tried to introduce the Command pattern. But I need to do a better job this time around...

• 13th and 14th weeks

  We cover work through a payroll system case study, and we refactor student solutions to a simple file reader. Both are ripe with recurrences of patterns the students have seen, though I did not do as well as I might have last time on the file reader.

Of course, I also emphasize a number of patterns not specific to OOP but more general to the task of writing Simply Understood Code, such as Intention Revealing Name and Role Suggesting Temporary Variable Name. Thumbnail sketches of these patterns appear in the External Patterns section at the end of the paper.

Object

Use an instance of a class, not a procedural "main" program.

Example: DieTester

See Kent's pattern of the same name.

Composed Method

See Kent's pattern of the same name.

Access Method

See Syntax Procedure for a functional equivalent.

See Kent's Getting Method and Setting Method patterns.

Functions for Loops

See pattern of the same name by Dick Gabriel.

Application Class

Is this really a pattern?

You are writing an OO program in a hybrid language such as C++ or Java.

Where do you put the functionality that starts the program?

In Java, you can put your main() method in any one of the classes of your application. But this allows the main() method to access private data and methods in the class.

Therefore, write a separate application class considting of a single main() method.

When your application is intended as a test of one or more classes, you can now be certain that your class works without clients needing to break encapsulation.

Adapter

Example: MouseListener interface -- MouseAdapter class -- a limited mouse listener

Subclass is Client

You are writing a class. You expect the class to be subclassed later.

How do you provide future subclasses access to your class' instance variables?

A subclass will inherit your class' instance variables; they become part of the subclass' state. You would like to allow the subclass to manipulate its inherited instance variables in much the same way it manipulates its locally-defined instance variables.

The simplest solution is to make the instance variables protected. In this way, the inherited variables are accessible to the subclass but not accessible to client code. But if subclass code directly accesses inherited variables, then it becomes tightly couplied to the representation of the superclass. A change to the superclass can affect the subclass.

(You would like to preserve the encapsulation of your class...)

Therefore, make all of the class' instance variables private but provide protected access methods for use by future subclasses. (Link to Access Method pattern above.)

(For example...?)

(Resulting Context?)

Substitution

See idea behind Dwight's pattern of the same name in his Foundation Patterns paper.

When objects need to behave different ways, create a small hierarchy of roles that shares an interface, and then create an IV in the class typed to the interface/superclass.

Examples: payroll methods and employee classifications in the payroll case study

Object Recursion

See the idea in Bobby Woolf's Object Recursion paper.

Example: cloning in Java

Nice use of delegation...

Decorator

See GoF pattern of the same name.

Example: physical and virtual streams in Java

Composite

See GoF pattern of the same name.

Example: frames holding frames in the Java AWT

Strategy

See GoF pattern of the same name.

Example: frames and layout managers

Iterator

See GoF pattern of the same name.

Example: use of Enumerations in Java

Abstract Factory

See GoF pattern of the same name.

Example: creation of an Enumeration for an vector or hash table

State

See GoF pattern of the same name.

Related to Substitution.

Example: the roles played by a video in a video store, over time.

Command

See GoF pattern of the same name.

Example: the functionality for operation buttons on a calculator

External Patterns

The following patterns are not a part of Roundabout but are referred to by one or more of its patterns. Links to on-line versions of the patterns are provided where available.

• ?? Caching Temporary Variable (Beck)
  • Problem: How do you improve the performance of a method, in the face of repeated expression evaluations?
  • Solution: "Set a temporary variable to the value of the expression as soon as it is valid. Use the variable instead of the expression in the remainder of the method."

• ?? Collecting Parameter (Beck)
  • Problem: How do you return a solution that is the result of collaboration among several procedures?
  • Solution: Add a parameter to each of the procedures. Use this parameter as a means of passing the current state of the computation among the collaborators.

• Composed Procedure (Called "Composed Method" by Beck)
  • Problem: How should you divide a program into components?
  • Solution: "Divide your program into [procedures] that do one identifiable task. Keep all of the operations in a [procedure] at the same level of abstraction. This will naturally result in programs with many small [procedures], each a few lines long."

• Getting Method (Beck)
  • Problem: How do you provide access to part of a structure?
  • Solution: Provide a procedure that returns the value of that part of the structure. Give it a name that indicates its meaning in the structure.

• Intention Revealing Name (Called "Intention Revealing Selector" by Beck)
  • Problem: How do you name a procedure?
  • Solution: Name procedures for what they accomplish.

• Role Suggesting Temporary Variable Name (Beck)
  • Problem: What do you call a temporary variable?
  • Solution: "Name temporary variables for the role they play in the computation. Use variable naming as an opportunity to communicate valuable tactical information to future readers."

• Simply Understood Code (Gabriel)
  • Problem: People need to be comfortable reading a piece of code before they feel confident that they understand it and can modify it.
  • Solution: "Arrange the important parts of the code so it fits on one page. Make that code understandable to a person reading it from top to bottom. Do not require the code to be repeatedly scanned in order to understand how data is used and how control moves about."

Related Ideas

Similar concepts in other programming styles

Teaching undergraduates using patterns

Acknowledgements

My colleagues at the 1998 Hot Topic on Elementary Patterns provided plenty of ideas and valuable discussion: Owen Astrachan, Joe Bergin, Robert Duvall, Ed Epp, and Rick Mercer. I also thank the many members of the patterns community who have encouraged us to write this sort of pattern, especially Ken Auer and Kent Beck.

References

1. Kent Beck, Smalltalk Best Practice Patterns, Prentice Hall, New York, 1997.

2. Richard Gabriel, Simply Understood Code, quoted by Jim Coplien, "The Column Without a Name: Software Development as Science, Art, and Engineering," C++ Report, July/August 1995, pp. 14-19. Also appears at "http://c2.com/cgi/wiki?SimplyUnderstoodCode".

3. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns, Addison-Wesley, New York, 1995.

4. Bobby Woolf, "The Object Recursion Pattern", Proceedings of the 1998 Pattern Languages of Programming Conference, August 1998.