Design pattern

from Wikipedia, the free encyclopedia

Design Patterns ( english design patterns ) are proven solution templates for recurring design problems both in architecture and in software architecture and development . They thus represent a reusable template for problem solving that can be used in a certain context. In recent years, the design pattern approach has also attracted increasing interest in the field of human-computer interaction . Originally the term was used in architecture by Christopher Alexander .

Types of design patterns

Example of a design pattern in UML (here the design pattern "prototype")

There are different types of design patterns. The following types were originally distinguished:

Generation pattern (English creational patterns )
Used to create objects. They decouple the construction of an object from its representation. The object generation is encapsulated and outsourced in order to keep the context of the object generation independent of the concrete implementation, according to the rule: "Program on the interface, not on the implementation!"
Structure patterns (English structural patterns )
Make software design easier with pre-made templates for relationships between classes.
Behavior patterns (English behavioral patterns )
Model complex behavior of the software and thus increase the flexibility of the software with regard to its behavior.

Other types were added later for those design patterns that did not fit into any of the three types mentioned. Including, for example

Object-relational mapping pattern
Used to store and access objects and their relationships in a relational database.

history

In a tradition going back to Vitruvius , the architect Christopher Alexander put together a collection of design samples between 1977 and 1979. The main task of these patterns is to involve the residents of the structures to be built in the design process. The approach to design patterns was presented by Alexander as early as 1964 in Notes on the synthesis of form . In architecture, however, this idea has not spread as widely as it did later in software development.

Kent Beck and Ward Cunningham took up Alexander's ideas from architecture in 1987 and developed design patterns for the creation of graphical user interfaces in Smalltalk . A year later, Erich Gamma began his doctorate at the University of Zurich on the general transfer of this method to software development. In parallel, James Coplien worked on pattern-like idioms for C ++ from 1989 to 1991 and published his book Advanced C ++ Idioms in 1991 .

Erich Gamma completed his doctorate in the same year and then went to the United States . There he published the book Design Patterns - Elements of Reusable Object-Oriented Software in 1994 together with Richard Helm , Ralph Johnson and John Vlissides , in which 23 design patterns are described. These four authors are among developers also by her nickname Gang of Four ( Gang of Four , shortly GoF known) and helped with her book design patterns to their breakthrough. Occasionally GoF is also used as a reference for the book in question. Unlike Alexander, who wrote his patterns primarily for laypeople, the GoF patterns are aimed at software developers and not users.

Requirements and benefits

A good pattern should

  • solve one or more problems ,
  • offer a proven concept,
  • based on real designs,
  • go beyond the obvious,
  • involve the user in the design process,
  • Show relationships that encompass deeper structures and mechanisms of a system .

Design patterns usually contain references to other patterns. With the help of these it is possible to develop sample languages .

The primary use of a design pattern is to describe a solution to a particular class of design problem. Another benefit comes from the fact that each pattern has a name. This simplifies the discussion among developers, since one can speak abstractly about a structure. For example, software design patterns - in contrast to idioms - are initially independent of the specific programming language.

If the use of design patterns is documented, there is a further benefit in that the description of the pattern creates a reference to the discussion of the problem context and the advantages and disadvantages of the solution.

disadvantage

The successful use of design patterns in the past can lead one to view the design patterns as a miracle weapon and a guarantee of good design. Inexperienced developers may be inclined to use as many familiar patterns as possible, overlooking the fact that in their case a more elegant solution might be possible without using patterns. Design samples do not guarantee that the design will be good. In this respect, applying too many or inappropriate design patterns is an anti-pattern .

Sample catalogs

Design patterns are usually collected in so-called pattern catalogs (English "Design Pattern Catalog") following the example of the books by Christopher Alexander and the Gang of Four. These describe the individual patterns like a catalog based on their properties. For example, in the book Design Patterns - Elements of Reusable Object-Oriented Software, these properties are : Task, Other Names, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Example Code, Known Uses, Related Patterns.

In addition to the design sample catalog of the Gang of Four, there are a number of other catalogs. These include the books Patterns of Enterprise Application Architecture , Pattern-Oriented Software Architecture, Volume 1, A System of Patterns , Refactoring To Patterns and the Core J2EE Patterns . See section Literature .

List of patterns

The following table of design patterns contains design patterns from the Gang of Four (colored red), functional behavior patterns from Stuart Sierra (colored blue), and other design patterns from other catalogs. The first three columns represent the subsets into which the design patterns in the Design Patterns book have been categorized. The fourth column contains patterns for the object-relational mapping that were especially shaped by Martin Fowler (colored green). The fifth column contains such design patterns that cannot be assigned to any of the first four columns. It is not complete and partially overlaps with architectural patterns .

Generating patterns (Creational Design Patterns) Structural patterns (Structural Design Patterns) Behavior (Behavioral Design Patterns) Object-relational mapping pattern More patterns
Abstract Factory ( abstract factory pattern ) Adapter ( adapter pattern ) Observers ( observer pattern ) Data mapper Business delegate
Single piece ( singleton pattern ) Bridge ( bridge pattern ) Visitors ( visitor pattern ) Data access object Dependency injection
Builder ( builder pattern ) Container ( container pattern ) Interceptor ( interceptor pattern ) Data transfer object ( Data Transfer Object ) Extension Interface
Factory Method ( factory method pattern ) Decorator ( decorator pattern ) Interpreter ( interpreter pattern ) Table data gateway Fluent interface
Multiton ( multitone pattern ) Facade ( facade pattern ) Iterator ( iterator pattern ) Row data gateway Inversion of Control
Prototype ( prototype pattern ) Flyweight ( flyweight pattern ) Command ( command pattern ) Active Record Transaction Script
  Composition ( composite pattern or whole-part ) Memento ( memento pattern ) Unit of Work Table module
  Deputy ( proxy pattern ) Null object ( pattern NullObject ) Identity Map Page controller
  Half Object Plus Protocol Template Method ( template method pattern ) Lazy loading Template view
  Strategy ( strategy pattern ) Identity Field Transform View
    Mediator ( mediator pattern ) Dependent mapping Two-step view
    State ( state pattern ) Embedded value Application controller
    Chain of Responsibility ( Chain of responsibility ) Serialized LOB Remote facade
    State / Event Inheritance Mapper Locks
    Consequences Metadata mapping Session States
    Accumulator Query Object Repository
    MapReduce   Value Object
    Reduce / Combine   Registry
    Recursive expansion  
    Software pipelining  
    Process wrapper  
    Token  
    Page Object  

Other types of patterns

The work of the Gang of Four has stimulated many authors to publish further. This also gave rise to the problem that a pattern can no longer be easily classified as a design pattern. Rather, there are gradual differences in the granularity of patterns. For example, the Model-View-Controller (MVC) pattern is viewed by some as an architectural pattern , and by others (still) as a design pattern .

Examples of patterns that are not design patterns :

Anti-pattern

Where design patterns are common and well-known approaches to solving problems in software development, anti-patterns are negative examples of solutions that have already been carried out, which give indications as to which errors should be avoided.

After more and more positive experiences were benefiting from successfully completed tasks in software development, the focus was also on identifying and documenting the negative examples, i.e. recurring errors in software development.

See also

literature

Web links

Wikibooks: Design Patterns  - Learning and Teaching Materials

Individual evidence

  1. Andreas Zeller: Design sample on st.cs.uni-saarland.de (PDF, p. 2.)
  2. Erich Gamma , Richard Helm , Ralph E. Johnson , John Vlissides : Design pattern . Elements of reusable object-oriented software. Addison-Wesley, Munich 2004, ISBN 3-8273-2199-9 (English: Design Patterns. Elements of Reusable Object-Oriented Software. ).
  3. ^ A b Martin Fowler: Patterns of Enterprise Application Architecture . Addison-Wesley-Longman, Amsterdam 2002, ISBN 0-321-12742-0 .
  4. Christopher Alexander , Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksfahl-King, Shlomo Angel: Eine Muster- Sprach . Cities, buildings, construction. Löcker, Vienna 1995, ISBN 3-85409-179-6 .