Jump to content

Software design pattern

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 200.69.103.2 (talk) at 16:41, 18 August 2004. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Design patterns are standard solutions to common problems in object-oriented software design. The phrase was introduced to computer science in 1995 by the text Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0201633612). 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 implementation problems rather than design problems. Typically, a design pattern is thought to encompass a tight interaction of a few classes and objects.

History

Christopher Alexander was the first to mention the idea of patterns. He was an architect and an urban planner. Alexander thought about architecture and planning as a continuous reapplication of simple principles. He decided to extract these principles in a form independent from the specific problems they are used to solve. He started out by using mathematical methods to develop these principles, and then he defined a pattern language to reduce the complexity of formal methods. This idea is explained in his thesis Notes on the Synthesis of Form. Alexander wrote other books which included enhancements of his idea. In the software field, patterns were first devised in the late 1980’s. At that time, Ward Cunningham and Kent Beck were working on a project that involved designing user interface through Smalltalk. Due to difficulties and lack of good methods for designing user interface, they decided to use the idea of patterns that Christopher introduced. They designed five patterns for Smalltalk windows. Later on, they started writing a complete pattern language. They introduced ten other patterns and aimed to develop up to 150 patterns. They explained their work in a paper titled: Using Pattern Languages for Object-Oriented Programs. In 1991, Jim Coplien was developing a catalog about idioms. Idioms are patterns that are specific to C++. Coplien published his work in a book titled Advanced C++: Programming Styles and Idioms. At around the same time, Erich Gamma was working on his PhD thesis about object oriented software development. He realized the benefit of recording frequent design structures. Coplien and Gamma and others met at a series of OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) workshop and exchanged their ideas about patterns.

Four people (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides – known collectively as the Gang of Four) wrote the first book about design patterns entitled Design Patterns – Elements of Reusable Object-Oriented Software. In this book, they classified patterns into Creational, Behavioral, and Structural patterns. They introduced around 22 patterns. They presented a way to document design patterns. This book is considered as the basic reference to design patterns and many works were based on it. In 1993, a small group of people interested in patterns formed the Hillside Generative Patterns Group. They formed the first conference on patterns Pattern Languages of Programming (PLoP) in 1994.

Advantages

A very important advantage of design patterns is the fact that they speed up the development process by providing an almost ready made solution that has been used earlier and proved to be efficient. 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.

Moreover, design patterns allow for a generalized solution that does not depend on understanding a specific design problem from all its aspects, and thus ease reusing this solution. There is a possibility that someone had experienced your problem in a similar context and found a suitable solution for it. However, as it is, you need to understand the details of this person's design in order to adopt the same solution to your problem. If this person documented his or her solution in the format of a design pattern, you would not have to grasp these details. Additionally, having documented a design pattern will make it easier to recognize a problem in one's design and thus find a solution directly. Moreover, the fact that this design pattern is documented with a specific name makes it easier to communicate about it among developers.

Classification

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

Documentation

The documentation for a design pattern should contain enough information about the problem 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.

References

  • 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.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Software_design_pattern&oldid=5326289"