This chapter is from the book
This chapter is from the book
This chapter is from the book
5.1 Fundamental Terminology
What’s a Design Pattern?
The simplest way to describe a 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.
The notion of a pattern is already a fundamental part of everyday life. Without acknowledging it each time, we naturally use proven solutions to solve common problems each day. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns.
Design patterns are helpful because they:
- represent field-tested solutions to common design problems
- organize design intelligence into a standardized and easily “referencable” format
- are generally repeatable by most IT 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
Furthermore, because the solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.
Let’s provide a simple (non SOA-related) example of a design pattern that addresses a user interface design problem:
Problem: How can users be limited to entering one value of a set of predefined values into a form field?
Solution: Use a drop-down list populated with the predefined values as the input field.
What this example also highlights is the fact that the solution provided by a given pattern may not necessarily represent the only suitable solution for that problem. In fact, there can be multiple patterns that provide alternative solutions for the same problem. Each solution will have its own requirements and consequences, and it is up to the practitioner to choose.
In the previous example, a different solution to the stated problem would be to use a list-box instead of a drop-down list. This alternative would form the basis of a separate design pattern description. The user-interface designer can study and compare both patterns to learn about the benefits and trade-offs of each. A drop-down list, for instance, takes up less space than a list box but requires that a user always perform a separate action to access the list. Because a list box can display more field lines at the same time, the user may have an easier time locating the desired value.
What’s a Compound Pattern?
A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns. Compound patterns are explained in detail at the beginning of Chapter 22.
What’s a Design Pattern Language?
A pattern language is a set of related patterns that act as building blocks in that they can be carried out in pattern sequences (or pattern application sequences), where each subsequent pattern builds upon the former. As explained shortly in the Historical Influences section, 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.
Some pattern languages are open-ended, allowing patterns to be combined into a variety of creative sequences, while others are more structured whereby groups of patterns are presented in a suggested application sequence. In this case, the pattern sequence is generally based on the granularity of the patterns, in that coarser grained patterns are applied prior to finer-grained ones that then build upon or extend the foundation established by the coarse-grained patterns. In these types of pattern languages, the manner in which patterns can be organized into pattern sequences may be limited to how they are applied within their groups.
Structured pattern languages are helpful because they:
- can organize groups of field-tested design patterns into proposed, field-tested application sequences
- ensure consistency in how particular design goals are achieved (because by carrying out sets of inter-dependent patterns in a proven order, the quality of the results can be more easily guaranteed)
- are effective learning tools that can provide insight into how and why a particular method or technique should be applied as well as the effects of its application
- provide an extra level of depth in relation to pattern application (because they document the individual patterns plus the cumulative effects of their application)
- are flexible in that the ultimate pattern application sequence is up to the practitioner (and also because the application of any pattern within the overall language can be optional)
This book in its entirety provides an open-ended, master pattern language for SOA. The extent to which different patterns are related can vary, but overall they share a common objective and endless pattern sequences can be explored. The relationship diagrams explained in the upcoming Pattern Relationship Figures section will often hint at common application sequences for a given pattern.
Chapters 6 and 11 single out sets of closely related patterns and structure them into groups organized into recommended application sequences that essentially establish primitive design processes. As a result, these collections of patterns could be classified as “mini” structured pattern languages that are still part of the overall master pattern language.
What’s a Design Pattern Catalog?
A design pattern catalog is simply a documented collection of related design patterns. Therefore, this book is also referred to as a catalog for design patterns associated with SOA and service-orientation.