The first thing to answer is: “Are patterns exclusive to object oriented systems, or are they applicable to other paradigms?” I say the latter, but they all tend to be written as OBJECT ORIENTED examples, so it might be unwise to talk about patterns before OBJECT ORIENTED . Instead, let the student learn patterns along with OBJECT ORIENTED, and then apply this new knowledge to the other areas.
I like the “just-in-time” approach, e.g., assign a problem that requires the Composite pattern, let the students do it on their own, and then explain the Composite pattern as a high-level answer to that aspect of the assignment. Perhaps have them go back and refactor their code afterwards.
In the classes, how do you handle the structural/responsibility phases of OBJECT ORIENTED design? Are you using OBJECT ORIENTED on structures first, or on behavior? That might help you decide whether to introduce the structural patterns or the behavioral patterns first. But this is a really difficult issue, for which patterns should follow, not lead.
It would be nice to see some studies on this. Is it better to introduce patterns one at a time as the problems require them? Or should you provide an overall list of the patterns up front, and then let the students look them up as they need?
Should the students do it the hard way first, then use patterns, or should they be shown patterns then told to use them? I like the former, but I cannot claim it is justified.
Also, applying a pattern could take a little longer than just “hacking” a solution for an assignment. I don’t know.
Finally, how should you plan the “high-level” architecture? For example, take the Composite pattern: Should one write an abstract Composite set of classes then subclass for the problem domain? Or should one just be aware of the pattern, then write code for it within the problem domain classes? Frankly, I haven’t seen anything which shows that the former is better. And this decision is going to affect the sequence of your class.
I mentioned the Composite pattern twice. I’m guessing this is the most common pattern. It is also very easy to understand. The Observer is also very common. Is the class doing GUIs, or is it doing business classes? Go with the easiest, common patterns in the particular area in which you are teaching.
The way I see it - use the “just in time” approach. I think the concept of patterns may be introduced, as part of a discussion covering such terms as paradigms, idioms, frameworks etc. Of course, the students will absorb the real meaning of these, with time. After that specific patterns can be introduced when they are applicable.
One method that seems worthwhile to me is the “case study” approach. For example exercises about iterators can follow the pattern, or point to it for further study.
Ram said,
September 19, 2007 @ 12:50 amNo, the method of teaching design patterns to computer science students is not fully clear to me.