Joseph Bergin

Patterns have swept over the object-oriented development community. From humble beginnings in which poets (Richard Gabriel, for example) who happen to be computer scientists were reading architects (Christopher Alexander) who happened to be trying to improve the quality of life, the software patterns movement has now generated several independent conferences on at least two continents. One hope now is that patterns can be used to energize the introductory computer science curriculum, making it more efficient, so that more difficult material can be effectively handled earlier than can typically be done with other techniques.

A pattern is a solution to a recurring problem in a context. A pattern language is a set of interrelated patterns that interact to solve a larger problem or which serve as alternative solutions to a given problem. A pattern is an attempt to capture the best practice in a domain and transfer that knowledge to other practitioners. Patterns do not express new ideas. Patterns express the tried and proven within a given domain. The importance of patterns comes from the fact that the problems we face in building software recur. It is especially true that the knowledge captured by elementary patterns is needed everyday in the lives of software developers. Programmers for example write loops every day. If a set of patterns can capture best practice in writing loops and can transmit this effectively to students, the students will have learned important lessons in a well-structured way.

The title of this paper is presumptuous since the techniques recommended here are not proven by long experience. I don’t think that they are particularly new, but the application to patterns may be novel. I would like to start a conversation among educators about how patterns can be effectively used in the beginning courses in the curriculum to see if their promise is justified.

My personal goal is to explore whether patterns can be an effective means of introducing object oriented design to first year students. I see a great need to do this as early as possible as any program large enough to require more than one function must be designed. If we don’t teach design from a rational standpoint, then students will need to pick up ad-hoc methodologies that will need to be unlearned before more rational methodologies can be effectively learned. This is very inefficient and wastes precious time in the undergraduate curriculum. To meet this goal, however, requires that we have efficient ways to use patterns themselves.

I think that a course that was strictly organized around patterns would not be especially effective, any more than a course that is strictly organized around language syntax features. Many pattern books are catalogues that are good for reference by the initiated, but not useful for learning by novices. Even the professional pattern community is starting to feel that these books are less useful than they might otherwise be, because they don’t adequately show the interconnections between things.

Patterns can be used to introduce material in the first courses provided that students can see and recognize patterns. Patterns can also be used to summarize and capture the essence of materials taught earlier. The latter task is easier to achieve in the form of chapter summaries in books, for example, or hand outs at the end of a lecture or lab session. The difficulty is with finding ways to use patterns to introduce material. For this to be effective, students must first be made aware of what a pattern is, how it can be applied, and how to look for situations in which it can be applied.

My advice is that a course should not be overloaded with patterns. In the first course it is probably best to limit the number of unrelated patterns to fewer than ten. A few more can be covered if they are especially simple and integrate well into a pattern language. For a specific example, there is a simple pattern language appended to this paper. It consists of several patterns, but they all integrate well. A first course could handle more than one of these little pattern languages, but probably not more than six or so.

But for such patterns to be effective at all, other than summarizing standard lectures, the student must become used to the ideas and practices of patterns. Two basic teaching techniques that I use at various times are (1) subtlety and (2) explicitness. These form opposite ends of a scale in my mind. Sometimes one is more powerful than the other. In the case of teaching patterns, I think that movement from subtlety toward explicitness is appropriate.

To make this more explicit, what I recommend is that the first time a solution to a problem occurs, perhaps in a code fragment that fulfills some simple specification, the instructor may simply note to the students that there is a general principle here that has been applied to get the solution and this principle will be explored shortly.

The next time the same pattern is applied, the instructor can recall the first use and point out the similarities and especially the thinking that goes behind the view that the situations are similar and so the solutions are similar. The pattern can, perhaps, be named at this point, but otherwise not made explicit.

The third or fourth time that the pattern appears, the instructor would be well advised to make it explicit and to point out the nature of the pattern and some of the forces that lead to its use.

If one does this for two or three distinct patterns, then the student will begin to become familiar with the form of patterns and their use. It will then become possible to discuss patterns as a separate topic, abstracting from the individual patterns that have been taught. The instructor can spend a bit of time going over the essential elements of patterns and pattern languages and the syntax used to express them formally.

Once this has been done patterns can be used to introduce solutions to problems. A scenario can be presented and one or two patterns applicable to the solution can be presented and discussed. At this stage the forces at play in the selection/solution process seem to be most important to discuss. This is because students don’t always have the background to see these forces. A typical example of this is the rather low regard most students have for the problems of software maintainability and the fact that many software development practices ease the maintenance problem at the expense of seeming extra complexity in simple problems.

It should be clear from the above that to structure a course this way requires careful thought so that the similar contexts in which the use of patterns can be shown are made to recur within the course. The instructor needs to choose and lay out topics with an eye to including opportunities for application of the few chosen patterns that will be used. One way to do this is to examine an existing course looking for pattern possibilities.

Another important question to be answered by the course designer is which specific patterns and pattern languages should be included. Here the best current advice seems to be to look for areas in which students have difficulty. Getting loops right is a common area of difficulty for many students, for example. Here a rich sharing of experience among educators can help a lot so that patterns may be shared but, more importantly, so that they may be refined by passing through several minds.

There are two additional uses of patterns and pattern catalogs in instruction. The instructor may use a pattern, pattern language, or pattern catalog as a guide to what to teach and as a teaching outline. I point the reader to the loop patterns developed by Epp and others, for example. Secondly, an instructor can give students one of the typical pattern syntax guides, such as that used in GOF or elsewhere, and ask students to provide a written summary of a lecture or of a topic in the form of a pattern, with special attention to the forces, for example.