1w50: Difference between revisions
No edit summary |
No edit summary |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Importance of Design Patterns == | |||
Over the last few years, patterns have been gained attention in the software community. The use of patterns has helped solve issues faced while designing and reusing applications and libraries. These patterns capture knowledge from various parts of software developing. But as the number of patterns increases, the need to organize the patterns becomes more important. There should be a strong classification scheme to organize patterns in a library and help users in finding and storing patterns. Developing such a classification scheme involves finding useful criteria that should reflect natural properties of patterns | |||
== Buschman et al == | |||
According to Buschman, classification is based on three criteria. | |||
The functionality criteria classifies patterns based on the specific functionality that the design pattern will be used for. | |||
The structural principles classifies patterns based on the architectural patterns that the design pattern is utilizing. | |||
{| class="wikitable" | |||
|- | |||
! Functionality !! Structural Principle | |||
|- | |||
| Creation || Abstraction | |||
|- | |||
| Communication || Encapsulation | |||
|- | |||
| Access || Separation of concerns | |||
|- | |||
| Computation of complex tasks || Coupling and cohesion | |||
|} | |||
Patterns which belong to the sub category ''creation'' specify the manner in which to instantiate certain complex recursive or aggregate object structures. Patterns belonging to the subcategory ''communication'' describes the communication protocol to be followed during the remote or independent development of certain collaborating objects. Patterns of the ''access'' category will describe the scope of a particular object. Patterns belonging to the category organizing the ''computation of complex tasks'' specify the way in which responsibility can be allocated among collaborating objects. | |||
Patterns belonging to the subcategory ''abstraction'' gives an abstract overview of functionality in a software system. Patterns belonging to the subcategory ''encapsulation'' hide details of objects to eradicate dependencies.Patterns in the subcategory ''separation of concern'' segregates specific responsibilities into different objects or components to solve a particular task or provide a certain service. Patterns belonging to the category ''coupling and cohesion'' will ease out the structural and communicational dependencies between strongly coupled objects. | |||
== Coad == | |||
Coad organizes his pattern classification around a certain pattern which will further serve as a template for other patterns that follow. | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! | ! Pattern !! Description | ||
|- | |- | ||
| | | fundamental pattern || template for other patterns | ||
|- | |- | ||
| | | aggregate patterns || patterns that interact with transaction players | ||
|- | |- | ||
| | | plan patterns || patterns that interact with a plan player | ||
|- | |- | ||
| | | interaction patterns || Patterns which interact with the other players | ||
|} | |} | ||
== Pree == | |||
Pree classification is based on the structure of the design pattern. | |||
*Basic inheritance and interaction patterns | |||
*Patterns for structuring object-oriented software systems | |||
*Patterns based on recursive structures | |||
*Patterns relying on abstract coupling | |||
*Patterns related to the MVC-framework | |||
== Zimmer == | |||
Zimmer classification provides a new classification of the GoF design pattern proposed by Gamma et all. Three kinds of relationships are defined and a pattern is categorized based on what relationship it supports. | |||
*X uses Y in its solution | |||
X uses a design pattern Y as part of its solution. | |||
*Variant of X uses Y in its solution | |||
X may or may not utilize Design pattern Y as part of its solution. | |||
*X is similar to Y | |||
X and Y address a similar kind of problem. | |||
== Similarities and Differences in the Classification approach == | |||
In contrast to the classification by Gamma et. al, a pattern can belong to more than one category per criterion in Buschman et. al classification. | |||
Zimmer uses the relationships that Gamma et. al describe in each pattern's "Related Patterns" section. These relationships address a wide range of issues from “the pattern uses another pattern in its solution" to “the pattern is similar to another pattern in constructing object structures". Therefore there are extensive similarities in the classification scheme. | |||
Coad neither stress the importance of a classification nor does he describe his organization of patterns in a thorough manner. | |||
== References== | |||
{{http://www8.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm}} | |||
{{Relationships between Design Patterns-Walter Zimmer}} |
Latest revision as of 03:43, 4 October 2012
Importance of Design Patterns
Over the last few years, patterns have been gained attention in the software community. The use of patterns has helped solve issues faced while designing and reusing applications and libraries. These patterns capture knowledge from various parts of software developing. But as the number of patterns increases, the need to organize the patterns becomes more important. There should be a strong classification scheme to organize patterns in a library and help users in finding and storing patterns. Developing such a classification scheme involves finding useful criteria that should reflect natural properties of patterns
Buschman et al
According to Buschman, classification is based on three criteria. The functionality criteria classifies patterns based on the specific functionality that the design pattern will be used for. The structural principles classifies patterns based on the architectural patterns that the design pattern is utilizing.
Functionality | Structural Principle |
---|---|
Creation | Abstraction |
Communication | Encapsulation |
Access | Separation of concerns |
Computation of complex tasks | Coupling and cohesion |
Patterns which belong to the sub category creation specify the manner in which to instantiate certain complex recursive or aggregate object structures. Patterns belonging to the subcategory communication describes the communication protocol to be followed during the remote or independent development of certain collaborating objects. Patterns of the access category will describe the scope of a particular object. Patterns belonging to the category organizing the computation of complex tasks specify the way in which responsibility can be allocated among collaborating objects.
Patterns belonging to the subcategory abstraction gives an abstract overview of functionality in a software system. Patterns belonging to the subcategory encapsulation hide details of objects to eradicate dependencies.Patterns in the subcategory separation of concern segregates specific responsibilities into different objects or components to solve a particular task or provide a certain service. Patterns belonging to the category coupling and cohesion will ease out the structural and communicational dependencies between strongly coupled objects.
Coad
Coad organizes his pattern classification around a certain pattern which will further serve as a template for other patterns that follow.
Pattern | Description |
---|---|
fundamental pattern | template for other patterns |
aggregate patterns | patterns that interact with transaction players |
plan patterns | patterns that interact with a plan player |
interaction patterns | Patterns which interact with the other players |
Pree
Pree classification is based on the structure of the design pattern.
- Basic inheritance and interaction patterns
- Patterns for structuring object-oriented software systems
- Patterns based on recursive structures
- Patterns relying on abstract coupling
- Patterns related to the MVC-framework
Zimmer
Zimmer classification provides a new classification of the GoF design pattern proposed by Gamma et all. Three kinds of relationships are defined and a pattern is categorized based on what relationship it supports.
- X uses Y in its solution
X uses a design pattern Y as part of its solution.
- Variant of X uses Y in its solution
X may or may not utilize Design pattern Y as part of its solution.
- X is similar to Y
X and Y address a similar kind of problem.
Similarities and Differences in the Classification approach
In contrast to the classification by Gamma et. al, a pattern can belong to more than one category per criterion in Buschman et. al classification. Zimmer uses the relationships that Gamma et. al describe in each pattern's "Related Patterns" section. These relationships address a wide range of issues from “the pattern uses another pattern in its solution" to “the pattern is similar to another pattern in constructing object structures". Therefore there are extensive similarities in the classification scheme. Coad neither stress the importance of a classification nor does he describe his organization of patterns in a thorough manner.
References
Template:Http://www8.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm
Template:Relationships between Design Patterns-Walter Zimmer