Different Levels of Abstraction

Dividing patterns into clusters makes them more manageable. If you are building the front end of a Web application, start with the Web Presentation cluster, take the quick tour, and see what other patterns are related to this cluster. Keep in mind, though, that different people may be interested in different aspects of building a Web application, depending on the role they are playing or the stage of the project. A developer may be most interested in the most efficient implementation of the Page Controller pattern on the Microsoft .NET Framework, while an architect may be more interested in deciding whether to use a three-tiered or a four-tiered application architecture.

Level of abstraction, therefore, is a useful way to categorize patterns so that different user groups can find the patterns that correspond most closely to their area of interest. Dividing the patterns from general to more specific detail also helps you decide which patterns to consider first. You may want to think about how many tiers your application should have before you consider the intricacies of ASP.NET caching directives described in the Implementing Page Cache with ASP.NET pattern.

One way categorize the patterns is to divide the pattern graph into the three levels shown in Figure 2.4.

Figure 2.4: Levels of abstraction

This division largely coincides with the terminology used in some of the most influential books about software patterns.

Architecture Patterns

“An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.” [Buschmann96]

ESP follows the Buschmann, et al. definition of architecture patterns. These patterns describe how to structure an application at the highest level. For example, the Layered Application pattern is an architecture pattern.

Design Patterns

“A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.” [Gamma95]

Design patterns provide the next level of refinement, as described in the seminal work by Gamma, et al. Many of the iconic patterns, such as Model-View-Controller or Singleton, are in this layer.

Implementation Patterns

The patterns community refers to more detailed, programming-language-specific patterns as idioms. This definition works well for software patterns. However, the scope of this guide is not just software, but software-intensive systems, including the deployment of the software onto hardware processing nodes to provide a holistic business solution. Therefore, ESP modifies the definition of an idiom given in Pattern-Oriented Software Architecture (POSA) [Buschmann96] to reflect the broader scope and relabels these patterns as implementation patterns:

An implementation pattern is a low-level pattern specific to a particular platform. An implementation pattern describes how to implement particular aspects of components or the relationships between them, using the features of a given platform.

The ESP implementation patterns demonstrate how to implement design concepts using the.NET Framework. In some cases, the framework already incorporates the bulk of the work, making the developer’s task easier.

Note

Even though POSA [Buschmann96] defines idioms as patterns and The Timeless Way of Building [Alexander79] includes implementation patterns in his original pattern work, there is a debate among some members of the pattern community as to whether implementation patterns are true patterns. Regardless of how they can be classified, they are very helpful when thinking about patterns, and are therefore included in this guide.

Dividing the collection of patterns into three levels of abstraction makes it easier for different user groups to identify patterns that relate to their fields of interest and expertise. The resulting model flows from high-level organization, through progressive refinement of subsystems and components, down to the implementation of these patterns using platform-specific technology.