In software engineering, software design patterns are general solutions that can be reused for problems that are common in certain contexts in software design. This is not a finished design that can be converted directly into a source or machine code. This is a description or template for how to troubleshoot issues that can be used in various situations. A design pattern is a formalized best practice that programmers can use to solve common problems when designing applications or systems.
Object-oriented design patterns usually show relationships and interactions between classes or objects, without specifying the final application class or the objects involved. Patterns that imply a mutable status may not be suitable for functional programming languages, some patterns may be rendered unnecessary in languages ​​that have built-in support to solve the problem they are trying to solve, and object-oriented patterns are not always suitable for non-object-oriented languages.
The design pattern can be seen as a structured approach to intermediate computer programming between the level of programming paradigm and the concrete algorithm.
Video Software design pattern
History
The pattern originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of ​​applying patterns for programming - especially the pattern language - and presenting their results at the OOPSLA conference that year. In the years that followed, Beck, Cunningham and others followed up on this work.
Although the design pattern has been applied practically for a long time, the formalization of the concept of design patterns languished for several years.
Maps Software design pattern
Practice
Design patterns can accelerate the development process by providing a proven and proven development paradigm. Effective software design requires considering issues that may not be visible until later in the implementation. Newly written code can often hide delicate problems that take time to be detected, problems that can sometimes cause major problems down the road. Reusing design patterns helps prevent such subtle problems, and it also increases code readability for coders and architects who are familiar with the patterns.
To achieve flexibility, design patterns typically introduce additional levels of deceit, which in some cases can complicate the resulting design and undermine application performance.
By definition, patterns must be programmed again into each application that uses them. Because some authors see this as a step back from software reuse provided by components, researchers have been working to turn patterns into components. Meyer and Arnout were able to provide full compartmentation or a portion of two thirds of the pattern they tried.
Software design techniques are difficult to apply to wider issues. Design patterns provide a general solution, documented in a format that does not require specific-specific issues.
Structure
The design pattern consists of several parts (see Ã,§ Documentation below). What's interesting is the section Structure, Participants, and Collaboration. This section describes the design motifs: the prototypical micro-architecture that developers copy and customize with their custom designs to resolve the recurring issues described by the design patterns. Micro-architecture is a set of program constituencies (eg, Classes, methods...) and their relationships. Developers use design patterns by introducing in their design these prototypical micro-architectures, meaning that micro-architectures in their designs will have structures and organizations that are similar to the design motifs chosen.
Domain-specific pattern
Attempts have also been made to codify design patterns within specific domains, including the use of existing design patterns as well as domain-specific design patterns. Examples include user interface design patterns, information visualization, secure design, "safe usability", Web design and business model design.
The annual Language Pattern event of the Conference Programming includes many examples of domain-specific patterns.
Classification and list
The patterns of design were originally grouped into categories: creational patterns, structural patterns, and behavioral patterns, and described using the concepts of delegation, aggregation, and consultation. For more background on object-oriented designs, see merging and cohesion, inheritance, interfaces, and polymorphisms. Another classification also introduces the idea of ​​architectural design patterns that can be applied to software-level architectures such as Model-View-Controller patterns.
Creative patterns
Structure pattern
Behavior pattern
The concurrency pattern
Documentation
The documentation for the design patterns describes the context in which the patterns are used, the forces in the context that the pattern wants to accomplish, and the suggested solutions. There is no standard format for documenting design patterns. In contrast, different formats have been used by different pattern authors. However, according to Martin Fowler, certain pattern forms have become more famous than others, and consequently a common starting point for writing new patterns of writing. One example of the commonly used documentation format is that used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (collectively known as the "Gang of Four", or GOF for short) in their book Design Pattern > me. It contains the following sections:
- Pattern and Classification Names: A unique and descriptive name that helps identify and refer to patterns.
- Purpose: A description of the purpose behind the pattern and the reason for its use.
- Also Known As: Another name for the pattern.
- Motivation (Troop): A scenario consisting of a problem and context in which this pattern can be used.
- Entry into force: Situation where this pattern can be used; context for the pattern.
- Structure: Graphical representation of the pattern. Class diagrams and Interaction diagrams can be used for this purpose.
- Participants: List of classes and objects used in their patterns and roles in the design.
- Collaboration: Description of how classes and objects used in patterns interact with each other.
- Consequences: Description of results, side effects, and trade offs caused by the use of patterns.
- Implementation: Description of pattern implementation; solution part of the pattern.
- Sample Code: Illustration of how patterns can be used in programming languages.
- Known Uses: Examples of real usage of the pattern.
- Related Patterns: Another pattern pattern-related pattern; a discussion of the differences between similar patterns and patterns.
Criticism
The concept of design patterns has been criticized in several ways.
The design pattern may just be a sign of some missing features of the given programming language (Java or C for example). Peter Norvig points out that 16 of the 23 patterns in the Design Pattern (especially focused on C) are simplified or eliminated (via direct language support) in Lisp or Dylan. Related observations were made by Hannemann and Kiczales applying some of the 23 design patterns using aspect-oriented programming language (AspectJ) and showing that code-level dependencies have been removed from implementation 17 of 23 design patterns and program oriented aspects can simplify the application of design patterns. See also Paul Graham's essay "Revenge of the Nerds".
In addition, the use of inappropriate patterns can increase unnecessary complexity.
Another point of criticism is the lack of an updated version since the book Design Pattern was published in 1994.
See also
References
Further reading
Source of the article : Wikipedia
0 Comments