Smalltalk Patterns


Software developers have been attempting to reuse the software they write for many years. The introduction of Object Oriented programming languages (and Smalltalk in particular) went a long way towards improving the potential for reuse but still the goal remains largely unfulfilled.

Other engineering professions have been successfully reusing design solutions by collecting them in "handbooks" available to all members of the profession. These have been particularly successful in the mechanical engineering and architectural fields. In some sense the flexibility of software has been to its own detriment. It's very easy to copy a piece of software, modify the copy and produce a new product. You can't do that quite so easily with a suspension bridge. This supposed ease with which new software can be created has steered its development away from more traditional engineering discipline. We're finally realizing, however, that it is design reuse that's even more important than code reuse if the software industry is to achieve its goals.

Software Design Patterns are the latest candidate for a Software Engineer's Handbook. For Dolphin Smalltalk we have put together a series of Pattern Sheets that document how and why certain design solutions should be undertaken. Many of these pages are tailored specifically to solving problems with Dolphin but you may like to check out our list of further reading references for more general purpose material.

The Pattern sheets

The Pattern form was perhaps first introduced by Christopher Alexander in his books, a Timeless Way of Building and A Pattern Language. He stated, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Although Alexander's patterns were directed to solving architectural problems his notion still holds well for software.

For clarity, each pattern sheet has the same format. First, there is a paragraph that describes the context in which the pattern should be used. This often presents links to higher level patterns but eventually ends in a statement of the problem that the pattern aims to solve. Following the problem description is a section that describes a potential solution. There maybe a number of forces, both good and bad, that act upon the solution and govern its applicability, and these are discussed in a section entitled consequences. In most cases, following this, there will appear one or more examples of the pattern in use. Within the pattern body there may be links to other lower level sheets which may be needed to complete the pattern; to fill out its details. At the end of a sheet there may be related patterns, a number of cross references to other patterns that have not yet been mentioned in the overall discussion but are still related to the current pattern in some way.

From this, you can see that no pattern stands alone but each is part of a hierarchy with larger patterns above it and smaller, more detailed, patterns below it.

Pattern Mining

Any Pattern Language will be dynamic and grow as new patterns are discovered (a process known as Pattern Mining). We will be adding to the available set as new versions of the Education Centre are released but you may also wish to add patterns of your own. There is a Pattern Template to help you with this.

Using the Patterns

The intended method of use is quite straightforward.