Encyclopedia  |   World Factbook  |   World Flags  |   Reference Tables  |   List of Lists     
   Academic Disciplines  |   Historical Timeline  |   Themed Timelines  |   Biographies  |   How-Tos     
Sponsor by The Tattoo Collection
Design pattern (computer science)
Main Page | See live article | Alphabetical index

Design pattern (computer science)

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.

Table of contents
1 History
2 Advantages
3 Classification
4 Documentation
5 Critique
6 Related topics
7 References
8 External links

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 1980s. 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:

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

References

External links