Monday, July 23, 2012

Introduction to Design Patterns

What is a Pattern?

When experts need to solve a problem, they seldom invent a totally new solution. More often they will recall a similar problem they have solved previously and reuse the essential aspects of the old solution to solve the new problem. They tend to think in problem-solution pairs.
Identifying the essential aspects of specific problem-solution pairs leads to descriptions of problem-solving patterns that can be reused.
The concept of a pattern as used in software architecture is borrowed from the field of (building) architecture, in particular from the writings of architect Christopher Alexander.
"A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate." [Buschmann].
Where software architecture is concerned, the concept of a pattern described here is essentially the same concept as an architectural style or architectural idiom in the Shaw and Garlan book.
In general, patterns have the following characteristics [Buschmann]:
  • A pattern describes a solution to a recurring problem that arises in specific design situations.
  • Patterns are not invented; they are distilled from practical experience.
  • Patterns describe a group of components (e.g., classes or objects), how the components interact, and the responsibilities of each component. That is, they are higher level abstractions than classes or objects.
  • Patterns provide a vocabulary for communication among designers. The choice of a name for a pattern is very important.
  • Patterns help document the architectural vision of a design. If the vision is clearly understood, it will less likely be violated when the system is modified.
  • Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage the construction of software with well-defined properties
  • Patterns are building blocks for the construction of more complex designs.
  • Patterns help designers manage the complexity of the software. When a recurring pattern is identified, the corresponding general solution can be implemented productively to provide a reliable software system.

Descriptions of Patterns

Various authors use different formats (i.e., "languages") for describing patterns. Typically a pattern will be described with a schema that includes at least the following three parts [Buschmann]:
  1. Context
  2. Problem
  3. Solution


The Context section describes the situation in which the design problem arises.


The Problem section describes the problem that arises repeatedly in the context.
In particular, the description describes the set of forces repeatedly arising in the context. A force is some aspect of the problem that must be considered when attempting a solution. Example types of forces include:
  • requirements the solution must satisfy (e.g., efficiency)
  • constraints that must be considered (e.g., use of a certain algorithm or protocol)
  • desirable properties of a solution (e.g., easy to modify)
Forces may complementary (i.e., can be achieved simultaneously) or contradictory (i.e., can only be balanced).


The Solution section describes a proven solution to the problem.
The solution specifies a configuration of elements to balance the forces associated with the problem.
  • A pattern describes the static structure of the configuration, identifying the components and the connectors (i.e., the relationships among the components).
  • A pattern also describes the dynamic runtime behavior of the configuration, identifying the control structure of the components and connectors.

No comments:

Post a Comment