Concept: Patterns |
Generalized solutions that can be implemented and applied in a problem situation (a context), and thereby eliminate one or more of the inherent problems.
Relationships
Related Elements | Architecture Layering Architecture Mechanism Design Mechanism Business Pattern Using Patterns
Main Description
#### 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 [ALE77] and The Timeless Way of Building [ALE79] 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 [ALU03], 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 [GAM95], 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 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. [BUS96] 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 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 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 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.
More Information
Concepts | Architecture Mechanism Design Mechanism Business Pattern
Guidelines | Layering Using Patterns
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright