Software design pattern

Design patterns (English design patterns ) are proven solution templates for recurring design problems in architecture as well as in software architecture and development. Thus, they represent a reusable template for problem solving, which is used in a particular context. In recent years, the approach of design patterns has also found increasing interest in the field of human-computer interaction. Originally the term was used in the architecture of Christopher Alexander.

Types of design patterns

There are different types of design patterns. These include

  • Algorithms strategy pattern (english algorithm strategy patterns ): they concern issues of strategic high-level description how to exploit the characteristics of a computing environment.
  • Computational design patterns (english computational design patterns )
  • Design pattern (English execution patterns ) relate to issues of application execution with the strategies in the implementation of data flows of operations ( tasks) and the synchronization of these devices.
  • Implementation strategy patterns (english implementation strategy patterns ) relate to issues of source code implementation to ensure that the Program organization and
  • General data structures with respect to parallel programming support.
  • Structural design patterns (English structural design patterns ) relate to issues related to developing structures of the applications at a high level.

History

The architect Christopher Alexander had put together a collection of design patterns in a tradition going back to Vitruvius between 1977-1979. The main task of this pattern is to involve the residents of the structures to be built into the design process. The approach for design patterns was described by Alexander in 1964 in Notes on the synthesis of form. In architecture, this idea has, however, not nearly as common as later in software development.

Kent Beck and Ward Cunningham intervened in 1987 to the ideas of Alexander from the developed architecture and design patterns for creating graphical user interfaces in Smalltalk. A year later, Erich Gamma started his PhD at the University of Zurich on the general extension of this methodology to software development. In parallel, James Coplien worked in the years 1989 to 1991 pattern similar idioms for C and published in 1991 his book Advanced C idiom.

Erich Gamma ended in the same year his doctorate and went afterwards to the United States. He brought in 1994 along with Richard Helm, Ralph Johnson and John Vlissides the book Design Patterns - Elements of Reusable Object-Oriented Software out in the 23 design patterns are described. These four authors are among developers also by her nickname Gang of Four ( Gang of Four, just 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 pattern, especially for the layman, the GoF patterns addressed to software developers and not to users.

Requirements and benefits

A good pattern should

  • Or solve several problems,
  • A proven concept offer,
  • Based on real designs
  • Go beyond the purely obvious,
  • Involve the user in the design process,
  • Relations show include the deeper structures and mechanisms of a system.

Design patterns usually include references to other patterns. Using this, it is possible to develop pattern languages.

The primary benefit of a design pattern is the description of a solution for a certain class of design problems. Another benefit arises from the fact that each pattern has a name. This simplifies the discussion among developers, since you can talk abstractly about a structure. Thus, about software design patterns - in contrast to idioms - first of all, regardless of the specific programming language.

If the use is documented design patterns, a further benefit results from the fact that a reference to the present there discussion of the problem context and the advantages and disadvantages of the solution is established by the description of the pattern.

Disadvantages

The successful use of design patterns in the past may lead us to look at the design patterns as a wonder weapon and a guarantee for good design. Inexperienced developers may be inclined to use as many well-known pattern, and overlook the fact that in their case perhaps a more elegant solution without the use of patterns is possible. Design patterns do not guarantee that the design is good. In this respect, the use of too many or inappropriate design pattern is an anti- pattern.

Sample catalogs

Design patterns are usually modeled after the books by Christopher Alexander and the Gang of Four in the so-called pattern catalogs (English " Design Pattern Catalog" ) collected. These describe the individual patterns catalog fashion based on their properties. These properties are for example in the book Design Patterns - Elements of Reusable following Object-Oriented Software: Task, Other Names, motivation, applicability, structure, participants, collaborations, consequences, implementation, sample code, known uses, related patterns.

In addition to the design pattern 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 Core J2EE Patterns. See section literature.

List of samples

The following table of design patterns Design patterns contains the Gang of Four ( colored red), functional behavioral patterns of Stuart Sierra ( colored blue ), and other design patterns in different catalogs. The first three columns represent the subsets into which the design patterns were categorized in the book Design Patterns. The fourth column contains patterns for object -relational mapping that have been particularly influenced by Martin Fowler ( green solution). The fifth column includes those patterns that do not fit into the first four columns. It is not exhaustive.

Other types of patterns

The work of the Gang of Four have stimulated many authors to other publications. The result was also the problem that a pattern can no longer be classified readily as design patterns. Rather, there are slight differences in the granularity of patterns. Thus, as the Model-View- Controller pattern (MVC ) architecture pattern by some as not (yet ) considered by others as a design pattern.

Examples of patterns which are not design patterns:

  • Analysis patterns characterize typical cases the requirement analysis.
  • Architecture patterns describe typical software architectures.
  • Idioms are occurring below the level of the draft in the programming model.
  • Communication patterns are related to the channels of communication between people of an organization.
  • Organization patterns describe elements of the structures of organizations.
  • Describe anti-patterns, " how not to do it."

Anti-Patterns

Where Design patterns are common and well-known approaches in software development in order to solve problems, as are anti-patterns negative examples of already implemented solutions that give clues as to what mistakes should be avoided.

As more has been benefiting from positive experiences of successfully completed tasks in software development, the focus was also on identifying the negative examples, ie, recurring errors in software development, and documented.

Ralph Johnson (computer scientist) Singleton pattern Data Access Object Dependency Injection Interceptor pattern Factory method pattern Decorator pattern Interpreter pattern Fluent Interface Multiton pattern Iterator pattern Inversion of Control Prototype pattern Flyweight pattern Active record pattern Memento pattern Model–view–presenter Null Object pattern Model View ViewModel Template method pattern MapReduce Lock (computer science) Software Pipelining Token Architectural pattern Software analysis pattern Reference model Reference architecture Wolfgang Pree Portland Pattern Repository
232412
de