The patterns in this book can be applied individually, each helping to resolve a particular set of forces related to concurrency and networking. However, just using these patterns in a stand-alone way limits their power unnecessarily, because real-world software systems cannot be developed effectively by resolving problems in isolation.
To increase the power of this book, this chapter shows how the patterns presented in Chapter 2 through 5 connect, complement, and complete each other to form the basis of a pattern language for building high-quality distributed object computing middleware, and concurrent and networked applications. We apply a two-step process to build this pattern language:
The pattern language we receive from applying this process is summarized in the following diagram. We recommend that you refer back to this diagram as you are reading the pattern language entries.
If a pattern uses another pattern in its implementation, it points to the pattern with an arrow. `Duplicate' entries for patterns that are frequently referenced by other patterns avoid having too many crossed relationships. Architectural patterns are shaded to indicate where the language `begins'.
In addition, this chapter outlines how many of these patterns can be applied outside the context of concurrency and networking, such as graphical user interfaces, component development, and general programming.
- Identify pattern relationships. Firstly we examine the self-contained descriptions of each pattern to determine which relationships listed in the patterns should be kept and which should be ignored. In particular, we only consider the `uses' relationship among the patterns and ignore all others, such as the `is used by' and transitive relationships. We also include all optional uses of other patterns into our set of relationships.
- Define pattern ordering. Secondly, based on the remaining relationships, we then define the order of the patterns in the language, that is, which patterns are entry points, which patterns follow, and which patterns are leafs. In our language, we define the patterns with the broadest scope--the architectural patterns--as its entry points. The `uses' relationships then define the ordering between the patterns.