In software engineering, design patterns are standard solutions to common problems in software design. The phrase was introduced to computer science in 1995 by the text Design Patterns: Elements of Reusable Object-Oriented Software. The scope of the term remained a matter of dispute into the next decade. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. Typically, a design pattern is thought to encompass a tight interaction of a few classes and objects.

Contents

1 Uses 2 Classification 3 Documentation 4 Critique 5 Related topics 6 References 7 External links

Uses

Design patterns can speed up the development process by providing almost ready-made solutions that have been used earlier and proved to be efficient.

Although many of the problems frequently encountered in software design have existing solutions, solutions can be difficult to adopt due to the need to understand their details. Design patterns address this problem by being general; a solution documented in the format of a design pattern can be understood without knowledge of the specific details involved. Moreover, the standardized naming of design patterns makes communication among developers easier.

Commonly used design patterns also have the potential of being revised and improved over time, and thus are more likely to perform better than home made designs.

Classification

Design patterns can be classified based on multiple criteria, the most common of which is the basic underlying problem they solve. According to this criterion, design patterns can be classified into various classes, some of which are:

• Fundamental patterns
• Creational patterns
• Structural patterns
• Behavioral patterns
• Concurrency patterns

Documentation

The documentation for a design pattern should contain enough information about the problem that the pattern addresses, the context in which it is used, and the suggested solution. Nonetheless, authors use their own layouts to document design patterns, and these layouts usually resemble the essential parts. The authors usually include additional sections to provide more information, and organize the essential parts in different sections, possibly with different names.

A commonly used format is the one used by the Gang of Four. It contains the following sections:

• Pattern Name and Classification: Every pattern should have a descriptive and unique name that helps in identifying and referring to it. Additionally, the pattern should be classified according to a classification such as the one described earlier. This classification helps in identifying the use of the pattern.
• Intent: This section should describe the goal behind the pattern and the reason for using it. It resembles the problem part of the pattern.
• Also Known As: A pattern could have more than one name. These names should be documented in this section.
• Motivation: This section provides a scenario consisting of a problem and a context in which this pattern can be used. By relating the problem and the context, this section shows when this pattern is used.
• Applicability: This section includes situations in which this pattern is usable. It represents the context part of the pattern.
• Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams can be used for this purpose.
• Participants: A listing of the classes and objects used in this pattern and their roles in the design.
• Collaboration: Describes how classes and objects used in the pattern interact with each other.
• Consequences: This section describes the results, side effects, and trade offs caused by using this pattern.
• Implementation: This section describes the implementation of the pattern, and represents the solution part of the pattern. It provides the techniques used in implementing this pattern, and suggests ways for this implementation.
• Sample Code: An illustration of how this pattern can be used in a programming language
• Known Uses: This section includes examples of real usages of this pattern.
• Related Patterns: This section includes other patterns that have some relation with this pattern, so that they can be used along with this pattern, or instead of this pattern. It also includes the differences this pattern has with similar patterns.

Critique

Some feel that the need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no "pattern" to label and catalog. It is also said that design patterns encourage navigational database-like structures instead of the allegedly cleaner relational approach where such structures are viewpoints instead of hard-wired into programming code. However, critics of the relational approach suggest that it does not integrate well enough with behavior. The level of coupling that should be supplied between behavior and data is a contentious topic.

Related topics

• Pattern mining
• Programming practice
• Refactoring
• Software engineering and List of software engineering topics
• Aggregate pattern
• Pedagogical patterns
• Portland Pattern Repository

References

• Erich Gamma, Richard Helm , Ralph Johnson , and John Vlissides : Design Patterns, Addison-Wesley, 1995, hardcover, 395 pages, ISBN 0201633612, Design Patterns CD, 1997 ISBN 0201634988
• Frank Buschmann , Regine Meunier , Hans Rohnert , Peter Sommerlad , Michael Stal : Pattern-oriented Software Architecture, Volume 1: A System of Patterns, John Wiley & Sons Ltd., ISBN 0471958697
• Douglas C. Schmidt , Michael Stal , Hans Rohnert , Frank Buschmann : Pattern-oriented Software Architecture. Volume 2: Patterns for Concurrent and Networked Objects, John Wiley & Sons Ltd., ISBN 0471606952
• Alan Shalloway , James R. Trott : Design Patterns Explained: A New Perspective on Object-Oriented Design, Addison-Wesley, ISBN 0201715945
• Martin Fowler: Patterns of Enterprise Application Architecture, Addison-Wesley, ISBN 0321127420
• Douglas C. Schmidt , Stephen D. Huston : C++ Network Programming: Mastering Complexity Using ACE and Patterns, Addison-Wesley, ISBN 0201604647
• Alexander, Christopher et al. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, New York.

• Beck, K.; Crocker, R.; Meszaros, G.; Coplien, J.O.; Dominick, L.; Paulisch, F.; Vlissides, J.;Software Engineering, 1996., Proceedings of the 18th International Conferenceon, 25-30 March 1996 .
• Mathijs den Burger. Design Patterns for Networking Applications in Java. March, 2002.
• Cooper, James W., The Design Patterns Java Companion. Addison-Wesley Design Patterns Series. October 1998.
• Cunningham, Ward and Kent Beck. Using a pattern language for programming . In Addendum to the Proceedings of OOPSLA'87, volume 23,5 of ACM SIGPLAN Notices, page 16 May, 1988.
• Fowler, M.; Patterns [software patterns] Software, IEEE, Volume: 20, Issue: 2, March-April 2003. Pages: 56 – 57.

External links

• Java J2EE pattern catalog
• The list of design patterns is entirely based on a wiki page http://c2.com/cgi/wiki?CategoryPattern.
• The definition of design pattern is based on the definition in Design Patterns.
• Many design patterns are described in mgrand's book
• Patterns Catalog
• The Object-Oriented PatternDigest
• Design Pattern Toolkit
• XML structural design patterns.
• Perl Design Patterns
• The PatternShare community - community site for sharing patterns.