Understanding Design Patterns and It’s importance
What is a Design Pattern?
The simplest way to describe a design pattern is that it provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection. Patterns in the software engineering world that revolve around the design of automated systems are referred to as design patterns.
Design Patterns are important because :
- represent field-tested solutions to common design problems
- organize design intelligence into a standardized and easily referenced format
- are generally repeatable by most software engineering professionals involved with design
- can be used to ensure consistency in how systems are designed and built
- can become the basis for design standards
- are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
- can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
- can sometimes be applied prior and subsequent to the implementation of a system
- can be supported via the application of other design patterns that are part of the same collection
- enrich the vocabulary of a given software engineering field because each pattern is given a meaningful name
- solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.
Note : even though design patterns provide proven design solutions, their mere use cannot guarantee that design problems are always solved as required. Many factors weigh into the ultimate success of using a design pattern, including constraints imposed by the implementation environment, competency of the practitioners, diverging business requirements etc.
What is a pattern language?
A pattern language is a set of related patterns that act as building blocks in that they can be carried out in one or more pattern application sequences where each subsequent pattern builds upon the former. The notion of a pattern language originated in building architecture as did the term pattern sequence used in association with the order in which patterns can be carried out.
What are Pattern Profiles
Most of the design patterns are documented in a pattern profile comprised of the following parts:
- Requirement — A requirement is a concise, single-sentence statement that presents the fundamental requirement addressed by the pattern in the form of a question. Every pattern description begins with this statement.
- Problem — The issue causing a problem and the effects of the problem are described in this section, which may be accompanied by a figure that further illustrates the “problem state.” It is this problem for which the pattern is expected to provide a solution. Part of the problem description can include common circumstances that can lead to the problem (also known as “forces”).
- Solution — This represents the design solution proposed by the pattern to solve the problem and fulfill the requirement. The solution is a short statement that may be further followed by a diagram that concisely communicates the final solution state. “How-to” details are not provided in this section but are instead located in the Application section.
- Application — This part is dedicated to describing how the pattern can be applied. It can include guidelines, implementation details, and sometimes even a suggested process.
- Mechanisms — When applicable, a pattern will be associated with a list of common mechanisms that can be implemented to apply the pattern. Usually, some of the mechanisms will have already been referenced in the Application section. The application of the pattern is not limited to the use of these mechanisms. Mechanisms in most cases are technology mechanisms. Technology mechanisms represent well-defined IT artifacts that are established within an IT industry and commonly distinct to a certain computing model or platform. The technology-centric nature of some areas requires the establishment of a formal level of mechanisms to be able to explore how a given pattern can be applied differently via alternative combinations of mechanism implementations. This not only standardizes proven practices and solutions in a design pattern format, it further adds standardization to pattern application options.
Note : Not all patterns are associated with mechanisms.
Compound patterns are comprised of common combinations of design patterns. A compound pattern can represent a set of patterns that are applied together to a particular program or implementation in order to establish a specific set of design characteristics. This would be referred to as joint application. Alternatively, the patterns that comprise a compound pattern can represent a set of related features provided by a particular program or environment. In this case, a coexistent application of patterns establishes a “solution environment” that may be realized by a combination of tools and technologies. When illustrating a compound pattern, a hierarchical representation is usually required, where the compound pattern name is displayed at the top, and the patterns that comprise the compound are shown underneath.
Let us pick an example of a Pattern Profile pertaining to “Brokered Authentication”. The following excerpt has been picked from the book SOA Design Patterns by Thomas Erl . You will see how the concept of “Brokered Authentication” has been explained through a pattern profile