CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification: Difference between revisions
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
While these are good starting points for patterns, it is very hard to make use of this information in different contexts. | While these are good starting points for patterns, it is very hard to make use of this information in different contexts. | ||
== | == Domain Specific Classification == | ||
Domain specific classification may help make patterns more useful in various contexts. This is because they solution to the problem will be more specific to the context. Here are some examples of where domain specific classification was used: | |||
# [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface] | |||
# [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization] | |||
# [http://simson.net/thesis/ Computer Security] | |||
# [http://developer.yahoo.com/ypatterns/ Web Applications] | |||
For example, when building a webapp it is useful to use the Model-View-Controller pattern to organize access and control to and from the domain data. This pattern is structural. However, if a novice developer was to start building a webapp from scratch, would they turn to the literature on MVC to start their webapp architecture? | For example, when building a webapp it is useful to use the Model-View-Controller pattern to organize access and control to and from the domain data. This pattern is structural. However, if a novice developer was to start building a webapp from scratch, would they turn to the literature on MVC to start their webapp architecture? | ||
| Line 25: | Line 32: | ||
I propose that a novice would not because it would be too difficult to understand 'how' MVC applies to their context, webapps. This is a failure of patterns and the existing pattern classification scheme. We propose that for software patterns to be more recognizeable and useful for the average developer, the specific context should be explicitly described. For example, the context of webapps, MVC solution is very different than the context in GUI applications. Although the same pattern can be used in both, the problems are solved differently. Thus we actually say MVC is a schema and not a pattern. This may be controversial so we shall provide evidence for why view is worthy of acceptance. | I propose that a novice would not because it would be too difficult to understand 'how' MVC applies to their context, webapps. This is a failure of patterns and the existing pattern classification scheme. We propose that for software patterns to be more recognizeable and useful for the average developer, the specific context should be explicitly described. For example, the context of webapps, MVC solution is very different than the context in GUI applications. Although the same pattern can be used in both, the problems are solved differently. Thus we actually say MVC is a schema and not a pattern. This may be controversial so we shall provide evidence for why view is worthy of acceptance. | ||
Although patterns always existed, they were first described in a book by Christopher Alexander called [http://en.wikipedia.org/wiki/A_Pattern_Language "A Pattern Language - Towns, Buildings, Construction"] | Although patterns always existed, they were first described in a book by Christopher Alexander called [http://en.wikipedia.org/wiki/A_Pattern_Language "A Pattern Language - Towns, Buildings, Construction"]. Looking at patterns from the perspective of architecture, we see that the context is very important. For example, repeatable solutions for construction of buildings exist only for very specific contexts. | ||
= Existing Work = | = Existing Work = | ||
Revision as of 23:50, 9 October 2009
Originality, Clarity, Coverage, Definitions, Examples, Links, Organization.
Definition
A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns.
A more abstract concept than a pattern is a schema. A schema does not necessarily have any context but it does have structure and attributes. Many times schemas and patterns are mistakenly interchanged. The key to pattern recognition is that its context be described so that others can identify its usages.
The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we similar contexts we will have patterns or knowledge that develop from those solved problems.
Problem
The problem with patterns is classification and recognition or usage. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:
- Structural
- Behavioral
- Creational
While these are good starting points for patterns, it is very hard to make use of this information in different contexts.
Domain Specific Classification
Domain specific classification may help make patterns more useful in various contexts. This is because they solution to the problem will be more specific to the context. Here are some examples of where domain specific classification was used:
For example, when building a webapp it is useful to use the Model-View-Controller pattern to organize access and control to and from the domain data. This pattern is structural. However, if a novice developer was to start building a webapp from scratch, would they turn to the literature on MVC to start their webapp architecture?
I propose that a novice would not because it would be too difficult to understand 'how' MVC applies to their context, webapps. This is a failure of patterns and the existing pattern classification scheme. We propose that for software patterns to be more recognizeable and useful for the average developer, the specific context should be explicitly described. For example, the context of webapps, MVC solution is very different than the context in GUI applications. Although the same pattern can be used in both, the problems are solved differently. Thus we actually say MVC is a schema and not a pattern. This may be controversial so we shall provide evidence for why view is worthy of acceptance.
Although patterns always existed, they were first described in a book by Christopher Alexander called "A Pattern Language - Towns, Buildings, Construction". Looking at patterns from the perspective of architecture, we see that the context is very important. For example, repeatable solutions for construction of buildings exist only for very specific contexts.