The Pattern Form

Each pattern chapter in this book follows a consistent form. The form serves to formalize various aspects of each pattern's analysis. Every chapter is divided into the following sections, each of which addresses a particular pattern characteristic.

Pattern Name

A pattern's name serves as its most recognizable identifier. You can refer to pattern names in conversation and design documentation to explain which patterns you have employed without requiring a great deal of additional explanation. The convention in this book is to name patterns with short and unambiguous noun phrases. As a quick reference tool, any time a pattern name is mentioned outside its own chapter, it is followed by its page number in parentheses. An example of this is Optimistic Lock (405).

Description

The "Description" section is a sentence or short paragraph that succinctly explains the solution that a data access pattern provides. Use a pattern's description to quickly gauge its relevance to a particular design problem. The inside front cover of this book lists each data access pattern by name and gives its description as a quick reference.

Context

Engineers do not identify patterns from scratch. A pattern's originators have solved the same problem several times before coming up with a general solution. A pattern's context is a characterization of the problem or class of problems that it solves. This section also includes an illustrative example of the problem.

Applicability

A pattern's applicability is a list of conditions that indicate when its integration into a design is likely to be beneficial. Do not view these items as prerequisites, but rather as general guidelines.

Structure

The static structure of a pattern is illustrated using one or more Unified Modeling Language (UML) class diagrams. The interfaces, classes, and relationships in the diagram represent the pattern's fundamental concepts in broad terms. By no means should you feel obligated to use the precise entity names and relationships that this section defines. They intentionally use generic names to form the basis for subsequent discussion. It is anticipated that you will customize these entities as you apply them to a particular problem.

These terms make up a small naming convention for some of the patterns' structural entities:

• Client— The application or caller that consumes the pattern's implementation.

• Data— Data in its physical form, as stored in the database.

• Domain object— A domain-specific object representation of data.

• Accessor— An object whose role within a pattern is to encapsulate data access.

• Base— A generic, base implementation of an interface.

• Concrete— A specific, concrete implementation of an interface.

• Factory— An object whose primary role is to create or resolve implementation instances.

The "Structure" section also describes the role of each participant entity within the context of the pattern.

Interactions

This section describes the interactions among a pattern's participants. In essence, these interactions define how a pattern solves a problem. In some cases, the interactions are illustrated by one or more UML sequence diagrams. Sequence diagrams show the operational flow between participants as they carry out their individual roles. In other cases, this section describes interactions using only text, when that is more succinct than a sequence diagram.

Consequences

The consequences of a pattern describe the positive and negative effects that it can have on the overall system or application. This section contains one or more of each of these consequence types:

• Benefits— A pattern's benefits are its positive effects on the overall system. These usually line up with a pattern's description and embody the reason you employ the pattern in the first place.

• Drawbacks— A pattern's drawbacks describe its potentially degrading effects on the overall system. Not all drawbacks occur along with every application of a pattern, but they are conditions to keep in mind as you employ it.

• Tradeoffs— A pattern's tradeoffs describe considerations involving balancing mutually exclusive benefits and liabilities.

Strategies

This section describes useful techniques for implementing a pattern. It addresses the less obvious aspects of implementation details and offers suggestions for overcoming common problems.

Sample Code

The "Sample Code" section contains examples that usually implement the example scenario presented in the "Context" section. These are not full applications, but rather code blocks that focus directly on illustrating the pattern's key features.

All of the examples in this book use Java, and most of them use JDBC and SQL. JDBC is the standard relational data access interface for Java code, and SQL is the most common language for expressing relational database operations. The patterns in this book are by no means limited to Java, JDBC, and SQL. However, these technologies are widely understood and lend themselves to concise examples. I have made every effort to keep the sample code simple and clearly documented. As a result, you do not need to understand Java syntax details and semantics fluently to read the sample code.

Sample code intentionally omits necessary but uninteresting code details like import statements and connection uniform resource locators (URLs). These omissions are for the sake of brevity and retaining focus on the implementation aspects that relate to the pattern.

Related Patterns and Technology

Every data access pattern relates to other patterns, standards, or products in some way. This section cross-references these relationships. Examples of pattern relationships are:

• Usage— One pattern uses another if it builds on its foundation. For example, Domain Object Assembler (227) depends on implementations of Selection Factory (191), Domain Object Factory (203), and Update Factory (215). In a few cases, usage relationships extend across multiple levels. This section only describes direct relationships.

• Instantiation— One pattern is an instance of another if it refines its structure. For example, Resource Decorator (103) is an instance of the Decorator pattern described in [Gamma 1995] because it defines an application of it that is geared specifically to database resources.

• Alternative— Patterns are alternatives of each other if their solutions can be interchanged with similar results. Demand Cache (281) and Primed Cache (291) are examples of alternatives that can be applied to the same class of caching problems.

• Cooperation— Patterns cooperate when they can be applied together to form a comprehensive solution. For example, Cache Collector (325) can cooperate with Cache Accessor (271) to implement a robust caching solution.