Sun Java Center - J2EE Patterns

Print-friendly Version

What is a pattern?

Some people define a pattern as a recurring solution to a problem in a context. These terms-context, problem, and solution-deserve a bit of explanation. First, what is a context? A context is the environment, surroundings, situation, or interrelated conditions within which something exists. Second, what is a problem? A problem is an unsettled question, something that needs to be investigated and solved. A problem can be specified by a set of causes and effects. Typically, the problem is constrained by the context in which it occurs. Finally, the solution refers to the answer to the problem in a context that helps resolve the issues.

So, if we have a solution to a problem in a context, is it a pattern? Not necessarily. The characteristic of recurrence also needs to be associated with the definition of a pattern. Is that all? Perhaps not. Patterns should communicate design solutions to developers and architects who read and use them. As you can see, while the concept of a pattern is fairly simple, actually defining the term is more complex. Different experts in the field have offered a variety of definitions and explanations. If you are interested in these discussions, please check out the extensive, well-written literature noted in the bibliography.

We point you to the references so that you can dig more deeply into pattern history and learn or read about patterns in other areas. However, you should keep in mind the pattern definition we adopted in our patterns works. In our catalog, a pattern is described according to its main characteristics: context, problem, and solution, along with other important aspects, such as forces and consequences. The section describing the pattern template explains these characteristics in more detail.

Pattern Abstraction

A pattern describes, at some level of abstraction, an expert solution to a problem. Typically, a pattern is documented in a template form. While it is standard practice to document patterns in a specialized template format, it is by no means the only way to do so. Moreover, there are as many template formats as there are pattern authors, thus allowing for creativity in pattern documentation.

Patterns document solutions that exist at many levels of abstraction. There are patterns that describe solutions to everything from analysis to design and from architecture to implementation. Furthermore, patterns exist for numerous areas of interest and technologies. For example, there are patterns that describe how to work with a specific programming language or a specific industry segment, such as health care.

Identifying a Pattern

We have handled many J2EE projects at the Sun Java Center, and, over time, we have noticed that similar problems recur across these projects. We have also seen similar solutions emerge for these problems. While the implementation strategies varied, the overall solutions were quite similar.

When we see a problem and solution recur, we try to identify and document its characteristics using the pattern template. At first, we consider these initial documents to be candidate patterns. Candidate patterns are not added to the pattern catalog until we are able to observe and document their usage multiple times on different projects. We also undertake the process of pattern mining by looking for patterns in implemented solutions.

Then, there is the "Rule of Three", as it is known in the pattern community. This rule is a guide for transitioning a candidate pattern into the pattern catalog. According to this rule, a solution remains a candidate pattern until it has been verified in at least three different systems. Certainly there is much room for interpretation with rules such as this, but they help provide a context for pattern identification.

Often, similar solutions may represent a single pattern. When deciding how to form the pattern, it's important to consider how to best communicate the solution. Sometimes, a separate name improves communication among developers. If so, then consider documenting two similar solutions as two different patterns. On the other hand, it might be better to communicate the solution by distilling the similar ideas into a pattern/strategy combination.

Patterns vs. Strategies

When we started documenting the J2EE patterns, we made the decision to document them at a relatively high level of abstraction. At the same time, each pattern includes various strategies that provide lower-level implementation details. Through the strategies, each pattern documents a solution at multiple levels of abstraction. We recognize that we could have documented some of these strategies as patterns in their own right. However, we felt that our current template structure most clearly communicates the relationship of the strategies to the higher-level pattern structure in which they are included.

While we continue to have lively debates about converting these strategies to patterns, we have deferred these decisions for now, believing the current documentation to be clear. We have noted some of the issues with respect to the relationship of the strategies to the patterns:

• The patterns exist at a higher level of abstraction than the strategies.
• The patterns include the most recommended or most common implementations as strategies.
• Strategies provide an extensibility point for each pattern. Developers discover and invent new ways to implement the pattern, producing new strategies for well-known patterns.
• Strategies promote better communication, by providing names for lower-level aspects of a particular solution.