Design patterns are proven solutions to recurring design problems in architecture as well as in software architecture and development. They thus represent a reusable template for problem solving that can be used in a specific context. In recent years, the design pattern approach has also attracted increasing interest in the field of human-computer interaction.
Types of Design Patterns
There are different types of design patterns. Originally, the following types were distinguished:
- Creational Patterns: Used to create objects. They decouple the construction of an object from its representation. Object generation is encapsulated and outsourced to keep the context of object creation independent of the specific implementation, according to the rule: “Program on the interface, not on the implementation!”
- Structural Patterns: Make it easy to design software with pre-built templates for relationships between classes.
- Behavioral Patterns: Model complex behavior of the software and thus increase the flexibility of the software with regard to its behavior.
Later, other types were added for those design patterns that did not fit into any of the three types mentioned. These include, for example:
---
- Pattern for object-relational mapping: Used to store and access objects and their relationships in a relational database.
- Messaging Patterns: For creating, forwarding, and transforming data in the form of messages, including the required message channels and message endpoints, as well as system management components.
A good pattern should:
- solve one or more problems,
- offer a tried-and-tested concept,
- based on real-world designs,
- have more advantages than disadvantages
- go beyond the obvious,
- involve the user in the design process,
Identify relationships that encompass deeper structures and mechanisms of a system.
Design patterns usually include 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 problems. Further benefit comes from the fact that each pattern has a name. This simplifies the discussion among developers, as you can talk about a structure in the abstract. 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, a further benefit arises from the fact that the description of the pattern establishes a reference to the existing discussion of the problem context and the advantages and disadvantages of the solution.
