Design pattern (computer science)

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software "design". Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes.

History

Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year.cite conference
last=Smith
first=Reid
title=Panel on design methodology
conference=OOPSLA '87
booktitle=OOPSLA '87 Addendum to the Proceedings
doi=10.1145/62138.62151
month=October
year=1987, "Ward cautioned against requiring too much programming at, what he termed, 'the high level of wizards.' He pointed out that a written 'pattern language' can significantly improve the selection and application of abstractions. He proposed a 'radical shift in the burden of design and implementation' basing the new methodology on an adaptation of Christopher Alexander's work in pattern languages and that programming-oriented pattern languages developed at Tektronix has significantly aided their software development efforts."] cite conference
last=Beck
first=Kent
authorlink=Kent Beck
coauthors=Ward Cunningham
title=Using Pattern Languages for Object-Oriented Program
conference=OOPSLA '87
booktitle=OOPSLA '87 workshop on "Specification and Design for Object-Oriented Programming"
url=http://c2.com/doc/oopsla87.html
month=September
year=1987
accessdate=2006-05-26] In the following years, Beck, Cunningham and others followed up on this work.

Design patterns gained popularity in computer science after the book was published in 1994 (Gamma et al.). That same year, the first Pattern Languages of Programming Conference was held and the following year, the Portland Pattern Repository was set up for documentation of design patterns. The scope of the term remains a matter of dispute. Notable books in the design pattern genre include:

*cite book
title = Patterns of Enterprise Application Architecture
first = Martin
last = Fowler
authorlink = Martin Fowler
year = 2002
isbn = 978-0321127426
publisher = Addison-Wesley
*cite book
first = Erich
last = Gamma
authorlink = Erich Gamma
coauthors = Richard Helm, Ralph Johnson, and John Vlissides
year = 1995
title =
publisher = Addison-Wesley
isbn = 0-201-63361-2
*cite book
first = Gregor
last = Hohpe
coauthors = Bobby Woolf
year = 2003
title =
publisher = Addison-Wesley
isbn = 0-321-20068-3

Although the practical application of design patterns is a phenomenon, formalization of the concept of a design pattern languished for several years.cite web
url=http://www.iro.umontreal.ca/~ptidej/Publications/Documents/Research+report+Metamodeling+June03.doc.pdf
title=Design Patterns Formalization
first=Aline Lúcia
last=Baroni
coauthors=Yann-Gaël Guéhéneuc and Hervé Albin-Amiot
format=PDF
month=June
year=2003
publisher=École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes
location=Nantes
accessdate=2007-12-29]

Practice

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance.

By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns.cite journal
first=Bertrand
last=Meyer
authorlink=Bertrand Meyer
coauthors=Karine Arnout
title=Componentization: The Visitor Example
journal=IEEE Computer
publisher=IEEE
volume=39
issue=7
pages=23–30
month=July
year=2006
url=http://se.ethz.ch/~meyer/publications/computer/visitor.pdf]

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

tructure

Design patterns are composed of several sections (see Documentation below). Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a "design motif": a prototypical "micro-architecture" that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.

In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than "ad-hoc" designs.

Domain specific patterns

Efforts have also been made to codify design patterns in particular domains, including use of existing design patterns as well as domain specific design patterns. Examples include User Interface design patterns, [cite web
publisher = University of Helsinki, Dept. of Computer Science
last = Laakso
first = Sari A.
title = Collection of User Interface Design Patterns
accessdate = 2008-01-31
date = 2003-09-16
url = http://www.cs.helsinki.fi/u/salaakso/patterns/index.html] Information Visualization [cite journal
volume = 12
issue = 5
pages = 853
last = Heer
first = J.
coauthors = M. Agrawala
title = Software Design Patterns for Information Visualization
journal = IEEE Transactions On Visualization And Computer Graphics
date = 2006
url = http://vis.berkeley.edu/papers/infovis_design_patterns/
doi = 10.1109/TVCG.2006.178] and web design. [Cite web
title = Yahoo! Design Pattern Library
accessdate = 2008-01-31
url = http://developer.yahoo.com/ypatterns/]

The Pattern Languages of Programming Conference (annual, 1994) [http://hillside.net/plop/pastconferences.html proceedings] includes many examples of domain specific patterns.

Classification

Design Patterns originally grouped design patterns into the categories Creational Patterns, Structural Patterns, and Behavioral Patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern which may be applied at the architecture level of the software such as the Model-View-Controller pattern.

Documentation

The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution.cite web
first=Dick
last=Gabriel
authorlink=Richard Gabriel
title=A Pattern Definition
url=http://hillside.net/patterns/definition.html
accessdate=2007-03-06] There is no single, standard format for documenting design patterns. Rather, a variety of different formats have been used by different pattern authors. However, according to Martin Fowler certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern writing efforts.cite web
first=Martin
last=Fowler
authorlink=Martin Fowler
title=Writing Software Patterns
url=http://www.martinfowler.com/articles/writingPatterns.html
date=2006-08-01
accessdate=2007-03-06] One example of a commonly used documentation format is the one used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (collectively known as the Gang of Four, or GoF for short) in their book Design Patterns. It contains the following sections:

*Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
*Intent: A description of the goal behind the pattern and the reason for using it.
*Also Known As: Other names for the pattern.
*Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
*Applicability: Situations in which this pattern is usable; the context for the pattern.
*Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose.
*Participants: A listing of the classes and objects used in the pattern and their roles in the design.
*Collaboration: A description of how classes and objects used in the pattern interact with each other.
*Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
*Implementation: A description of an implementation of the pattern; the solution part of the pattern.
*Sample Code: An illustration of how the pattern can be used in a programming language
*Known Uses: Examples of real usages of the pattern.
*Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.

Criticism

In the field of computer science, there exist some criticisms regarding the concept of design patterns.

Workarounds for missing language features

Users of dynamic programming languages have discussed many design patterns as workarounds for the limitations of languages such as C++ and Java. For instance, the Visitor pattern need not be implemented in a language that supports multimethods. The purpose of Visitor is to add new operations to existing classes without modifying those classes. In C++, a class is declared as a syntactic structure with a specific and closed set of methods. In a language with multimethods, such as Common Lisp, methods for a class are outside of the class structure, and one may add new methods without modifying it. Similarly, the Decorator pattern amounts to implementing dynamic delegation, as found in Objective C, Self and JavaScript.

Peter Norvig, in "Design Patterns in Dynamic Programming", discusses the triviality of implementing various patterns in dynamic languages. cite web
url=http://norvig.com/design-patterns
title=Design Patterns in Dynamic Programming
first=Peter
last=Norvig
authorlink=Peter Norvig
date=1998-03-17
accessdate=2007-12-29] Norvig and others have described language features that encapsulate or replace various patterns that a C++ user must implement for themselves.

Does not differ significantly from other abstractions

Some authors allege that design patterns don't differ significantly from other forms of abstractionFact|date=March 2007, and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years.cite web
url=http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
title=MVC XEROX PARC 1978-79
first=Trygve
last=Reenskaug
authorlink=Trygve Reenskaug
accessdate=2008-06-09] It is further argued by some that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexander's pattern language as a form of documentation; a practice which is often ignored in the literature. Fact|date=February 2007

ee also

*Anti-pattern
*Architectural pattern
*Christopher Alexander
*Distributed design patterns
*GRASP (Object Oriented Design)
*Interaction design pattern
*List of software development philosophies
*List of software engineering topics
*Pattern theory
*Pedagogical patterns
*Portland Pattern Repository
*Refactoring
*Service-Oriented Modeling Framework (SOMF)

References

Further reading

;Books
*cite book
first = Christopher
last = Alexander
authorlink = Christopher Alexander
coauthors = Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel
year = 1977
title =
location = New York
publisher = Oxford University Press
isbn = 978-0195019193
*cite book
first = Kent
last = Beck
authorlink = Kent Beck
coauthors =
year = 2007
month = October
title = Implementation Patterns
publisher = Addison-Wesley
isbn = 978-0321413093
*cite book
first = Kent
last = Beck
authorlink = Kent Beck
coauthors = R. Crocker, G. Meszaros, J.O. Coplien, L. Dominick, F. Paulisch, and J. Vlissides
year = 1996
month = March
title = Proceedings of the 18th International Conference on Software Engineering
pages = 25-30
*cite book
first = Jan
last = Borchers
year = 2001
title = A Pattern Approach to Interaction Design
publisher = John Wiley & Sons
isbn = 0-471-49828-9
*cite book
first = James O.
last = Coplien
authorlink = Jim Coplien
coauthors = Douglas C. Schmidt
year = 1995
title = Pattern Languages of Program Design
publisher = Addison-Wesley
isbn = 0-201-60734-4
*cite book
first = James O.
last = Coplien
authorlink = Jim Coplien
coauthors = John M. Vlissides, and Norman L. Kerth
year = 1996
title = Pattern Languages of Program Design 2
publisher = Addison-Wesley
isbn = 0-201-89527-7
*cite book
title = Patterns of Enterprise Application Architecture
first = Martin
last = Fowler
authorlink = Martin Fowler
year = 2002
isbn = 978-0321127426
publisher = Addison-Wesley
*cite book
first = Eric
last = Freeman
coauthors = Elisabeth Freeman, Kathy Sierra, and Bert Bates
title = Head First Design Patterns
year = 2004
publisher = O'Reilly Media
isbn = 0-596-00712-4
*cite book
first = Richard
last = Gabriel
authorlink = Richard P. Gabriel
title = Patterns of Software: Tales From The Software Community
year = 1996
publisher = Oxford University Press
pages = 235
isbn = 0-19-512123-6
url = http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf
format = PDF
*cite book
first = Erich
last = Gamma
authorlink = Erich Gamma
coauthors = Richard Helm, Ralph Johnson, and John Vlissides
year = 1995
title =
publisher = Addison-Wesley
isbn = 0-201-63361-2
ref=book_Gamma1995
*cite book
first = Gregor
last = Hohpe
coauthors = Bobby Woolf
year = 2003
title =
publisher = Addison-Wesley
isbn = 0-321-20068-3
*cite book
first = Allen
last = Holub
authorlink = Allen I. Holub
year = 2004
title = Holub on Patterns
publisher = Apress
isbn = 1-59059-388-X
*cite book
first = Joshua
last = Kerievsky
year = 2004
title = Refactoring to Patterns
publisher = Addison-Wesley
isbn = 0-321-21335-1
*cite book
first = Michael
last = Kircher
coauthors = Markus Völter and Uwe Zdun
year = 2005
title = Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware
publisher = John Wiley & Sons
isbn = 0-470-85662-9
*cite book
first = Craig
last = Larman
authorlink = Craig Larman
year = 2005
title = Applying UML and Patterns
publisher = Prentice Hall
isbn = 0-13-148906-2
*cite book
first = Dragos
last = Manolescu
coauthors = Markus Voelter and James Noble
year = 2006
title = Pattern Languages of Program Design 5
publisher = Addison-Wesley
isbn = 0-321-32194-4
*cite book
first = Floyd
last = Marinescu
year = 2002
title = EJB Design Patterns: Advanced Patterns, Processes and Idioms
publisher = John Wiley & Sons
isbn = 0-471-20831-0
*cite book
first = Robert Cecil
last = Martin
authorlink = Robert Cecil Martin
coauthors = Dirk Riehle and Frank Buschmann
year = 1997
title = Pattern Languages of Program Design 3
publisher = Addison-Wesley
isbn = 0-201-31011-2
*cite book
first = Timothy G
last = Mattson
coauthors = Beverly A. Sanders and Berna L. Massingill
year = 2005
title = Patterns for Parallel Programming
Publisher = Addison-Wesley
isbn = 0-321-22811-1
*cite book
first = Alan
last = Shalloway
coauthors = James R. Trott
year = 2001
title = Design Patterns Explained, Second Edition: A New Perspective on Object-Oriented Design
publisher = Addison-Wesley
isbn = 0-321-24714-0
*cite book
first = John M.
last = Vlissides
authorlink = John Vlissides
year = 1998
title = Pattern Hatching: Design Patterns Applied
publisher = Addison-Wesley
isbn = 0-201-43293-5
*cite book
first = Charles
last = Weir
coauthors = James Noble
year = 2000
title = Small Memory Software: Patterns for systems with limited memory
publisher = Addison-Wesley
isbn = 0201596075
url = http://www.cix.co.uk/~smallmemory/

; Web sites
*cite web
url = http://www.c2.com/cgi-bin/wiki?HistoryOfPatterns
title = History of Patterns
work = Portland Pattern Repository
accessdate = 2005-07-28
*cite web
url = http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures
accessdate = 2006-01-20
title = Are Design Patterns Missing Language Features?
publisher = Cunningham & Cunningham, Inc.
*cite web
url = http://www.c2.com/cgi/wiki?ShowTrialOfTheGangOfFour
accessdate = 2006-01-20
title = Show Trial of the Gang of Four
publisher = Cunningham & Cunningham, Inc.

External links

* [http://hillside.net/patterns/onlinepatterncatalog.htm Directory of websites that provide pattern catalogs] at hillside.net.
* [http://www.go4expert.com/forums/showthread.php?t=5127 Explanation of design pattern in some simple examples] at go4expert.com.
* .
*
* [http://perfectjpattern.sourceforge.net PerfectJPattern Open Source Project] Design Patterns library that aims to provide full or partial componentized version of all known Patterns in Java.
* [http://jt.dev.java.net Jt] J2EE Pattern Oriented Framework
* [http://www.mcdonaldland.info/2007/11/28/40/ Printable Design Patterns Quick Reference Cards]
* [http://sourcemaking.com/design-patterns-and-tips 101 Design Patterns & Tips for Developers]
* [http://media.wiley.com/product_data/excerpt/28/04700590/0470059028.pdf On Patterns and Pattern Languages] by Buschmann, Henney, and Schmidt