Software design pattern

This is an old revision of this page, as edited by Kevin Saff (talk | contribs) at 22:32, 21 January 2004 (called->known as). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Design patterns are recurring solutions to problems in object-oriented design. The phrase was introduced to computer science in the 1990s by the text Design Patterns: elements of reusable object-oriented software. The scope of the term remained a matter of dispute into the next decade. Algorithms are not thought of as design patterns, since they solve implementation problems rather than design ones. Typically, a design pattern is thought to encompass a tight interaction of a few classes and objects.

A primary goal of design is to limit the amount of source change needed to change a program's observed behavior, but this can be difficult to achieve if a designer does not understand the implications of a design. The goal of pattern literature is to make the experience of past designers accessible to beginners and others in the field. A book of design patterns presents different solutions in a common format, to provide a language for discussing design issues.

The format has four essential parts, although the names and ordering differ by source:

  • Name - the name of the pattern, which eases discussion.
  • Problem - the problem the designer faces, given in context.
  • Solution - a detailed description of the solution to the problem.
  • Consequences - other results, some negative, of applying the pattern.

The original wiki was established largely to facilitate discussion of design patterns.

Poor (yet unfortunately common) solutions to common problems are sometimes known as anti-patterns.

See also amelioration pattern

Fundamental patterns

Creational patterns

Structural patterns

Behavioral patterns

Concurrency patterns

RealTime patterns

References