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:
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:
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.