Origins
The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. Alexander
has widely written on the subject of applying patterns to the design and construction of towns and buildings. Two of
his books, A Pattern Language [Alex77] and The Timeless Way of Building [Alex79] have had the greatest impact on the
software community and the adoption of software patterns for the design of software. His concepts of patterns and their
pattern language provides a model for the capture of software design expertise in a form that can then be re-applied in
recurring situations.
Patterns – A Definition
Today, the most commonly heard definition of software patterns is along the following lines, “A pattern is a proven
solution to a problem in a context.". This definition often servers as a starting point. A richer definition based on
Alexander’s work is offered by Gabriel in his A Timeless Way of Hacking [Core], each pattern is a three-part rule,
which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that
context, and a certain software configuration which allows these forces to resolve themselves.
Describing Patterns
The description of patterns can take many forms including narrative forms such as the Portland Form that emulates the
format used by Alexander and the keyword format made popular by Erich Gamma, et. al [GOF], the so called GoF format.
The GoF format uses the following keywords to describe object-oriented design patterns:
-
Pattern Name and Classification. Naming the pattern allows design to work at a higher level of abstraction using a
vocabulary of patterns. Gamma observes that finding a good name is one of the hardest problems of developing a
catalogue of patterns (see Pattern Catalogues below).
-
Intent. An answer to questions such as: What does the pattern do? What problem does it address?
-
Also Known As. Other names for the pattern.
-
Motivation. A concrete scenario that illustrates a design problem and how the pattern solves the problem;
-
Applicability. Instructions how you can recognize situations in which a pattern is applicable.
-
Structure. A graphical representation of the classes in the pattern.
-
Participants. The responsibilities of the classes and/or objects participating in the pattern.
Collaborations. How participants collaborate to fulfils their responsibilities.
-
Consequences.
-
Implementation. Guidance on the implementation of the pattern.
-
Sample Code. Code fragments illustrating the pattern’s implementation.
-
Known Uses. Real-world examples of where the pattern can be found.
-
Related Patterns. Synergies, differences and other pattern relationships
Though the GoF format is specifically aimed at object-oriented development it can be used with slight modification to
address other software patterns. A more general keyword format for software patterns based on Alexander’s principles
[Alex79] uses keywords such as problem, context, forces and solution.
Cataloguing Patterns
To assist with the identification and selection of patterns various classification schemes have been proposed. One of
the early schemes proposed by Buschmann et. al. [PLoPD1] using three classifiers, Granularity, Functionality and
Structured Principles. Of the three classifiers it is their granularity classifier that has remained popular.
Granularity classifies patterns by into three levels of abstraction:
1. Architectural Patterns: Architectural patterns express a fundamental structural
organization for a software scheme. Examples of architectural pattern included Layers, Pipes and Filters and
Model-View-Controller pattern.
2. Design Patterns: Software architecture usually consists of smaller architectural
units. These units are described by design patterns. Examples of design patterns include the GoF patterns.
3. Idioms. An idiom is the lowest level pattern and is specific to a programming
language.
Buschmann [BUS96] introduced four groups for categorising architectural patterns, structure, distributed systems,
interactive systems and adaptable systems. The following table shows the categorization of their architectural
patterns.
Categories for Architectural Patterns [BUS96]
Category
|
Pattern
|
Structure
|
Layers
Pipes and Filters
Blackboard
|
Distributed Systems
|
Broker
|
Interactive Systems
|
Model-View-Controller
Presentation-Abstraction-Control
|
Adaptable Systems
|
Reflection
Microkernel
|
For design patterns, Gamma [GoF] categorised their design patterns by purpose using three categories, creational,
structural and behavioural.
Pattern Languages
As well as the concept of patterns, Alexander also gave the software community the concept of a pattern language. The
purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would allow
those who work, study, and/or live in buildings to communicate effectively with the planners and designers of those
buildings. Alexander explains that when using a pattern language “we always use it as a sequence, going through the
patterns, moving always from the larger patterns to the smaller, always from the ones that create structure, to the
ones which then embellish those structures, and then to those that embellish the embellishments.”. In applying patterns
in this way, Alexander advocated the use of generative pattern languages, ones which given an initial context would
always lead to good design. Alexander [Alex97] states, “Thus, as in the case of natural languages, the pattern
language is generative. It not only tells us the rules of arrangement, but shows us how to construct arrangements – as
many as we want – which satisfies the rules.”
In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas and
the sequential application of patterns finds application in software design processes both waterfall and iterative that
successively apply architectural patterns, then design patterns and finally idioms to design and implement a software
system. Software processes however rely on the skills of the architect and developer roles to guide the application of
patterns rather than the use of a generative pattern language.
References
[PLoPD1] Pattern Languages of Program Design. J.O. Coplien, D.C. Schmidt, eds. Addison-Wesley, 1995.
[POSA] Pattern-Oriented Software Architecture--A System of Patterns. F. Buschmann, R. Meunier, H. Rohnert, P.
Sommerlad, M. Stal. Wiley, 1996.
[Core] Core J2EE Patterns: Best Practices and Design Strategies. Alur, Crupi, Malks, Prentice Hall/Sun Press,
2001
[GOF] Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995)
|