7.4 Patterns

While frameworks and components focus on the reuse of previously developed software, patterns focus on the reuse of expertise. A pattern is a general solution to problem; it is the result of abstracting what is common practice in solving a set of similar problems.

Patterns became a significant topic during the 1990s within an object community disappointed with the low level of reuse being achieved. Instead of concentrating on yet more new methods, the patterns movement looked at ways of building on the collective experience of solving frequent problems. There are many common and recurrent design problems for which good solutions exist and can be repeatedly applied. Design patterns capture such solutions in a way that can be applied generally. Moreover, by cataloguing problems and their solutions, patterns are a means to transfer expertise from the experienced to the novice software developer.

The patterns movement in software was inspired by a building architect, Christopher Alexander, who has written extensively on the use of design patterns for living and working spaces – homes, buildings, communal areas and towns (Alexander et al., 1977). According to Alexander, ‘each pattern describes a problem which occurs over and over again, in such a way that you can use this solution a million times over, without ever doing it the same way twice’.

Patterns became very popular following the publication of a catalogue of design patterns by a group of authors commonly known as the ‘Gang of Four’ (Gamma et al., 1995). Many more pattern catalogues have now been published, widening their original scope from design to most aspects of software development, including analysis and implementation.

Patterns from the literature have many different styles and serve many different purposes. Here is a brief overview of well-known pattern types.

Process patterns describe rules that can be followed when software systems are built, e.g. how to re-engineer an existing system with a pattern. In such a case the patter describes a strategy to follow. In 1997, Martin Fowler published a book on analysis patterns offering solutions to problems faced during business modelling, and in this case patterns describe general modelling issues. One analysis pattern presented by Fowler, for example, is called the Accountability Knowledge Level, and it indicates solution to deal with complexity in models by separating two types: a knowledge mode and an operational model. The Catalysis book (D'Souza et al., 1998) uses patterns to describe how the method proposed can be applied; each pattern presents a strategy for development. Fowler has also published (2002) another book on patterns for the design of enterprise systems architectures.

A design pattern is a set of classes and objects that solves a general design problem, and needs be customised for each specific context. A well-known design pattern from the ‘Gang of Four’ catalogue is the Observer pattern. It defines how to establish dependency between objects which guarantees that when one object changes state all its dependents are notified of that change. This pattern is implemented in many MVC-based interfaces and systems, in which a dependency mechanism exists between a set of domain objects (the model) and their visual representation (the views).

With most programming languages there is an accumulated knowledge of the experience of many programmers. Language patterns represent solutions to recurring programming problems within specific languages. Many language pattern catalogues exist; for instance, Kent Beck (1997) has written one on Smalltalk patterns, while Mark Grand (1998, 1999) has published two volumes on Java patterns. Such catalogues include patterns on how to access the variables of an object, how to name operations how to initialise objects. At the programming language level, language-specific patterns are usually known as idioms.