What Are Patterns? J2EE

Historical References

In the 1970s, Christopher Alexander wrote a number of books documenting patterns in civil engineering and architecture. The software community subsequently adopted the idea of patterns based on his work, though there was burgeoning interest in the software community in these ideas already.

Patterns in software were popularized by the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (also known as the Gang of Four, or GoF). Of course, while the Gang of Four work resulted in patterns becoming a common discussion topic in software development teams around the world, the important point to remember is that the patterns they describe were not invented by these authors. Instead, having recognized recurring designs in numerous projects, the authors identified and documented this collection.

Many software patterns books have been published since the GoF book, covering patterns for various domains and purposes. We provide references to a selected list of these titles and encourage you to investigate the other types of patterns described in these books.

Defining a Pattern

Patterns are about communicating problems and solutions. Simply put, patterns enable us to document a known recurring problem and its solution in a particular context, and to communicate this knowledge to others. One of the key elements in the previous statement is the word recurring, since the goal of the pattern is to foster conceptual reuse over time.

Here we examine some well-known definitions of patterns, beginning with one from Christopher Alexander in A Pattern Language:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
—Christopher Alexander

Alexander expands his definition further, and noted patterns figure Richard Gabriel discusses this definition in more detail. Gabriel offers his own version of Alexander's definition as applied to software:

Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves. [See A Timeless Way of Hacking.]

—Richard Gabriel

This is a fairly rigorous definition, but there are also much looser ones.

For example, Martin Fowler offers the following definition in Analysis Patterns:

A pattern is an idea that has been useful in one practical context and will probably be useful in others.

—Martin Fowler

As you can see, there are many definitions for a pattern, but all these definitions have a common theme relating to the recurrence of a problem/solution pair in a particular context.

Some of the common characteristics of patterns are

  • Patterns are observed through experience.
  • Patterns are typically written in a structured format.
  • Patterns prevent reinventing the wheel.
  • Patterns exist at different levels of abstraction.
  • Patterns undergo continuous improvement.
  • Patterns are reusable artifacts.
  • Patterns communicate designs and best practices.
  • Patterns can be used together to solve a larger problem.

Many great minds have spent a significant amount of time attempting to define and refine the notion of a software pattern. Suffice it to say, we do not presume to be great minds, nor do we wish to spend time expanding these discussions. Instead, we attempt to be true to aspects of these various definitions, focusing on the most simple and recurring theme in each.

Categorizing Patterns

Patterns, then, represent expert solutions to recurring problems in a context and thus have been captured at many levels of abstraction and in numerous domains. Numerous categories have been suggested for classifying software patterns, with some of the most common being

  • design patterns
  • architectural patterns
  • analysis patterns
  • creational patterns
  • structural patterns
  • behavioral patterns

Even within this brief list of categories, we see numerous levels of abstraction and orthogonal classification schemes. Thus, while many taxonomies have been suggested, there is no one right way to document these ideas.

Each pattern hovers somewhere between a design pattern and an architectural pattern, while the strategies document portions of each pattern at a lower level of abstraction. The only scheme we have introduced is to classify each pattern within one of the following three logical architectural tiers:

  • presentation tier
  • business tier
  • integration tier

At some point in the evolution of the pattern catalog, perhaps it will grow to a size that will warrant its being classified using a more sophisticated scheme. Currently, however, we prefer to keep things simple and not to introduce any new terms unnecessarily.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

J2EE Topics