CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification
Introduction
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?
This article is intended for experienced programmers who are well versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to Design Pattern. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.
This article relies heavily on the presentation by Imed Hammouda & Jakub Rudzki. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.
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 pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]
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 have similar contexts we will have patterns or knowledge that develop from those solved problems.
Example
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed. It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.
Problem
The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. 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.
Existing Work
The Gang of Four patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.
There is a good presentation regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:
- Domain
- Paradigm
- Granularity
- Purpose
- Scope
- Discipline
Domain
Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.
Factory method - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1] Object pool - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]
Adapter or Wrapper - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]
Interpreter - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]
Paradigm
Paradigm classification is a categorization of a pattern according a programming paradigm. In OOP patterns take forms of classes, objects and inheritance while in imperative programming patterns take form of procedures and functions.
Below are examples of patterns for functional logic languages taken from [2] and [3]
Opaque Type - Ensure that values of a datatype are hidden.
Locally Defined Global Identifier - Ensure that a local name is globally unique.
Incremental Solution - Compute solutions in an incremental manner.
Concurrent Distinct Choices - Ensure that a mapping from indexes to values is injective.
Constrained Constructor - Prevent invoking a constructor that might create invalid data.
Granularity
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]
Architectural patterns - refer to a software system at high level. Examples of these patterns would be Layer, Model-View-Controller and Multitier architecture
Design patterns - focus on subsystems and components. Examples of these patters would be Factory method, Object pool and Adapter or Wrapper
Idioms (coding patterns) - address the lowest level of a software system.
Purpose
Scope
Discipline
Article Definitions
Gang of Four - also known as GoF. The authors of the Design Patterns book.
Model-View-Controller - MVC for short, Architectural design pattern.
Links
- User Interface
- Information Visualization
- Computer Security
- Web Applications
- Pattern Classification
- A pattern catalog
- Classification of Object Oriented Design Patterns
- New Pattern Classification Approach
- J2EE Patterns
References
[2]Pattern Classification by Imed Hammouda & Jakub Rudzki
[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.