Chapter 16. Patterns and Strategies in EJB Design

What Are Patterns?

A pattern describes a proven approach for solving a problem. Throughout the rest of the engineering community, the concept of patterns is used extensively. When civil engineers are designing a new bridge, they don't start out by proposing their own theories on how to best build a bridge. They instead take advantage of the knowledge accumulated by the thousands of engineers who have built properly functioning bridges before them. In some cases, this knowledge has come the hard way as ideas that looked good on paper got added to the list of things not to do. No matter how the best patterns for designing a bridge have been developed, they define the starting point when a new bridge needs to be built.

A skilled civil engineer knows to start with what's been learned from the experience of others. With the exception of cosmetic issues, there's rarely a need to go outside the existing knowledge base of successful bridge designs. That's not to say that there isn't still work to be done. Every bridge is unique and must satisfy its exact set of requirements. The trick is to know how to select the patterns that apply to a particular design and use them correctly.

The concept of software patterns is not much different than applying patterns in other disciplines. Software developers have been building systems for many years . Some of the designs that were chosen worked very well and some did not. The idea of software patterns is to understand which ones worked and to apply the same solution when faced with the same problem or one similar to it. Often it's equally useful to know about attempted solutions that failed and to understand why they failed when a new pattern is proposed. Software patterns can be thought of as reusable ideas or solutions to solve a given problem. To make them easier to reuse, patterns are usually defined so that they're focused on a single design issue.

Another advantage of understanding and using patterns is that it allows those who understand the pattern to communicate a great deal of information very quickly. If you attend a design review and someone says "I used the blah pattern here" and you understand what the "blah" pattern is and what problem it solves , you can gain a quick understanding of that part of the design. Instead of having to study every detail of the design, you can focus only on making sure that the selected pattern is applicable to the problem at hand. Patterns allow developers to exchange a great deal of information simply by communicating a pattern name .

Different types of patterns are used throughout the software community. Patterns are often grouped as analysis patterns, design patterns, construction patterns, and so on. There are also many classifications of patterns within these groups. For example, some patterns are classified as proxy patterns and others are known as builder patterns. Classifying patterns helps you know which patterns to consider based on what aspect of a design you're addressing at the time. The idea is to have a catalog of patterns you can turn to and pull out what you need.

The standard for software design patterns was set by the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. You'll often hear these authors and their book referred to as the Gang of Four (GoF). If you've ever heard of patterns such as Singleton or Composite, this is the book that defines them. It's a highly regarded book that should be part of every developer's library. The documentation it provides for each pattern includes a name for the pattern, a description of the problem it's trying to solve, and a description and example of the solution. Different developers and organizations tend to follow their own formats for documenting software patterns, but you'll usually see the same basic information covered.