I. Introduction to the Use of Patterns
Expertise in almost any field includes knowledge of the basic procedures or common ways of doing things in that field. In most cases, these common ways of doing things are based on experience - people in the field discover what works and what does not work. The experts, then, are the people who have enough experience that they do not need to "re-invent the wheel" every time they encounter a new problem.

Of course, if every new problem were truly unique, one would have to start from scratch every time. It turns out, however, that in most fields of human endeavor new problems, challenges, issues, have some of the aspects of old problems, challenges, issues. This is what allows experts to use their expertise - they are familiar with what worked in the past and they have the ability to shape or adapt what worked to meet the specifics of the new problem. They recognize patterns!

It turns out that this ability to store, compare, and recognize patterns is one of the key components of human intelligence. Humans, in general, are not good logicians. We are not terribly fast in performing computations, we do not, in general, have photographic memories, and we do not find it easy to perform in-depth analysis of a situation. However, we are very good at pattern recognition.

Contrast the way humans and computers play chess. The latest chess machines play good chess by completely memorizing large sets of both opening and ending move sequences and by quickly analyzing the consequences of potential moves. They do their analysis by examining all or most of an opponents possible replies to a move, then all or most of their replies to the reply etc. - for many turns. Because they are so fast and have such good memories they can perform this process relatively quickly and with little chance of getting confused by all the variations they have to store at any one point.

Human chess experts do not perform the same way. Yes, they know the basic chess openings and end games and they can explore some of the consequences of a potential move but that is not what gives them their edge. Research has shown that what makes for a good chess player is the number of board patterns they can recognize and take advantage of. It seems that what a chess expert does in the midst of a game is somehow remember (recognize) the present board position as similar to a position they have seen before and then 'know' in general how to proceed. With this information they then need only explore a small set of move possibilities and replies based on the uniqueness of the present situation.

So, what does all this have to do with computer programming? It turns out that programming is no different from other areas of human endeavor. Solutions to programming problems follow a basic set of patterns whether one is talking about analysis and design or coding tasks. What makes one skilled at programming is partially the knowledge of these patterns. Of course, there is more to programming skill than knowing the patterns (and the syntax of some programming language) but it sure helps to be able to recognize and apply the basic patterns of the field.

The trick is acquiring the patterns without having the experience. Traditionally, students learn to program by writing and reading as many programs as possible and, in the process, absorbing an understanding of what works and does not work. Frankly, this is what you must do if you really want to be a skilled programming. You are especially encouraged to read as many programs as you can find the time for. It is faster than doing every problem on your own and you can begin to internalize a sense of what is 'right' or 'good'.

Having said that, however, it is possible to speed up the process a bit if the basic patterns used in analyzing, designing, and coding programs are made explicit. That is what this document tries to do. It presents some of the most common patterns used by programmers. These are broken up into three groups. First are the algorithmic patterns; second are some of the commonly used patterns in designing methods and, third, are a set of patterns specific to object-oriented design.

This document is not meant to be read through like a textbook although a quick read through might help you get a sense of what is available. It is really meant to be a reference - a tool to be used as you encounter a specific task in the course of developing a program.

Each algorithmic and method design pattern has associated with it a purpose statement. These represent a description of the problem this pattern is meant to solve or what goal it is meant to meet. You should try to find the pattern that best matches your present goal or whose purpose comes closest to matching what you are trying to do. Use the index of purpose statements found with the algorithmic patterns to help in this matching process.

At first you will probably need to refer to these patterns all the time. Indeed, at first, you should refer to them all the time, at least to check your work. Later, they will become part of your personal expertise and you won't need to use this external aid any more. Don't, however, fall into the trap of too many novices. Beginners often feel so overwhelmed with all that they need to do and their sense of not knowing where to start that they don't use any of the material available to them. This document is meant, most specifically, for those who are confused and unsure of what to do next. To use it, however, you must have some understanding of the problem at hand and have a commitment to working on some piece of that problem.

Here are the three basic categories of patterns covered in this material:

Algorithmic Patterns

Method Design Patterns

Class Design Patterns

The study of patterns in program development has recently moved well beyond what is discussed here. For more information on this subject, check out the web sites below:

Patterns Home Page

Portland Pattern Repository

GOOD LUCK!