Here are some techniques I've either used, read about, or heard people say that they use. What do you think of these approaches? Do you use or know of others? -- Eugene Wallingford

Owen, you can probably discuss this approach in more detail than I, given your time at UP'97. But here's my take:

- Show a system designed/implemented ad hoc, or at least without the aid of patterns.
- Show the same system after applying the patterns.
- Discuss the pros and cons of each version.

Typically, the "new and improved" version demonstrates the utility of the patterns in a number of ways.

Show the students a pattern. Then show lots of examples of the pattern in practice. Give the students lots of problems to solve using the pattern.

One potential down side: Students may not appreciate the pattern until they've experienced software that doesn't use the pattern.

Don't show the students the pattern description. Show the students lots of examples of the pattern. Give the students lots of problems to solve in which the pattern is likely to appear (and in which not using the pattern may result in sub-optimal solutions). Then either:

- Show the students the pattern description. Discuss its role in some of the examples and problems.
- Never show the students the pattern description. Hope that the students figure out the pattern on their own.

I suspect that Option 2 is essentially what many instructors do when they don't use a pattern-directed approach. We show lots of examples but leave the patterns and their names implicit. One of the things that I hope the interest in patterns will do is to expose in our minds this weakness in our instruction.

Dave Reed's SIGCSE'98 paper seems to follow a Figure It Out approach. Dave uses a particular pattern, Binary Reduction, as a theme for his CS1 course. Students see application of this beautiful pattern in number of unrelated contexts and soon recognize that something is going on. I can't remember if his paper describes using Option 1 or Option 2, that is, to what extent he explicitly talks about the pattern, or even uses the name, in class.

Back when I taught procedural programming courses (and when teaching procedural patterns for implementing methods in our OO CS1 course), I used an approach with elements of all three of the approaches above.

- At first, don't show the students the pattern description.
- Give the students an in-class exercise to solve in which the pattern is likely to appear and in which not using the pattern may result in a sub-optimal solutions.
- Give the students another such exercise.
- Examine candidate solutions to the two exercises. Identify the pattern, and give it a name.
- Perhaps show another example of the pattern in practice. Or, more liklely, give the students another in-class exercise to do, with explicit instructions to use the pattern. Assign a programming assignment in which the pattern plays a major role.