Patterns
m (→Pattern Families) |
|||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | What began as ''design patterns'' has grown into a diverse movement, including antipatterns, architectural patterns, organisational patterns etc. | + | [[Category:Patterns]] |
− | + | What began as ''design patterns'' has grown into a diverse movement, including antipatterns, architectural patterns, organisational patterns etc. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | ---- | + | == What is a Pattern? == |
+ | |||
+ | A pattern is an abstract representation of a solution to some form of problem. A pattern will detail the current situation, the cases where the pattern is applicable, the benefits and disadvantages of the pattern, other related patterns and the way of adding/changing code to apply pattern. | ||
+ | |||
+ | == Types of Patterns == | ||
+ | === Pattern Families === | ||
+ | This section is a starting point for the various families of patterns. These are the most well defined categories in the current literature. | ||
+ | |||
+ | * [[Design patterns]] - Patterns directly related to the composition and design of OO systems. These must be applicable to multiple domains (horizontal). | ||
+ | * [[Architectural patterns]] - Patterns specifically concerning architecting OO programs. | ||
+ | * [[Analysis patterns]] - Patterns related to a specific domain (vertical). | ||
+ | * [[Antipatterns]] - Patterns that detail a problem in an existing program and the solution. | ||
+ | * [[Amelioration patterns]] - Provide remedies to exiting code. | ||
+ | * [[Organisational patterns]] - Patterns around process and team management. (aka [[Management patterns]]) | ||
− | + | === Vertical vs Horizontal === | |
+ | This concept is proposed by a number of authors, including [[William Brown 1998]]. | ||
+ | * Vertical patterns are those that apply to a single domain (i.e. [[Analysis Patterns]]). | ||
+ | * Horizontal patterns are those that apply across domains. | ||
+ | == Are the families different? == | ||
+ | While authors have previously argued that all of these families of patterns are different, there is a growing thought that they contain many strong similarities to each other. There may be cases where certain families are actually not a logical distinction to draw. | ||
− | [[ | + | * [[Antipatterns]] & [[Amelioration patterns]] are arguably the same thing, both detail an existing problem and a solution. They both require an existing body of code. |
+ | * [[Design patterns]] & [[Architectural patterns]] are arguably an overlapping set of patterns. Potentially a distinction can be made at the level of abstraction at which they are used. | ||
+ | * [[Antipatterns]] & [[Design patterns]] - Potentially, these two areas of patterns have a large area of overlap. The only obvious difference is that Antipatterns require an existing problem that has already had an attempt at implementation, Design patterns require a problem at any stage of the design process to be used. |
Latest revision as of 06:06, 27 September 2009
What began as design patterns has grown into a diverse movement, including antipatterns, architectural patterns, organisational patterns etc.
Contents |
What is a Pattern?
A pattern is an abstract representation of a solution to some form of problem. A pattern will detail the current situation, the cases where the pattern is applicable, the benefits and disadvantages of the pattern, other related patterns and the way of adding/changing code to apply pattern.
Types of Patterns
Pattern Families
This section is a starting point for the various families of patterns. These are the most well defined categories in the current literature.
- Design patterns - Patterns directly related to the composition and design of OO systems. These must be applicable to multiple domains (horizontal).
- Architectural patterns - Patterns specifically concerning architecting OO programs.
- Analysis patterns - Patterns related to a specific domain (vertical).
- Antipatterns - Patterns that detail a problem in an existing program and the solution.
- Amelioration patterns - Provide remedies to exiting code.
- Organisational patterns - Patterns around process and team management. (aka Management patterns)
Vertical vs Horizontal
This concept is proposed by a number of authors, including William Brown 1998.
- Vertical patterns are those that apply to a single domain (i.e. Analysis Patterns).
- Horizontal patterns are those that apply across domains.
Are the families different?
While authors have previously argued that all of these families of patterns are different, there is a growing thought that they contain many strong similarities to each other. There may be cases where certain families are actually not a logical distinction to draw.
- Antipatterns & Amelioration patterns are arguably the same thing, both detail an existing problem and a solution. They both require an existing body of code.
- Design patterns & Architectural patterns are arguably an overlapping set of patterns. Potentially a distinction can be made at the level of abstraction at which they are used.
- Antipatterns & Design patterns - Potentially, these two areas of patterns have a large area of overlap. The only obvious difference is that Antipatterns require an existing problem that has already had an attempt at implementation, Design patterns require a problem at any stage of the design process to be used.