Columns

The pattern club

• By Dwight Deugo
• December 1, 2002

There comes a time when people working in the area of software development, design and architecture feel they understand the principles, facts, fundamental concepts, techniques, structures and other elements related to building software applications.

I often hear comments such as ''... is gaining more widespread acceptance and recognition as a useful abstraction and technology'' and ''we are uninterested in papers that describe yet another __ system.'' The question to answer now is what it is important for us to do next as a community.

To answer that question, we must first consider why we do not want to hear about another __ system. I won't answer for the various workshop and program committees, but I can propose an answer we often hear from others. Because there are so many __ systems and frameworks doing so many of the same things, what is the point of discussing another one that will do the same things in similar ways? However, I claim that these ''new'' systems validate, refine and demonstrate the reuse of many of the previously proposed and discussed elements. Moreover, they bring with them additional thoughts, understanding and clarifications. The problem is that when we report on a ''new'' system, these insights either get lost in the discussion of the system as a whole, or they are not reported at all. What we need to understand is the forces and context that lead to the decisions embedded in the designs and development of these systems, so that the information is there in case we need to make similar decisions in the future.

Many people, including me, propose that because we reach periods as a community when elements in software development are well understood and there are several examples of each, we should continue to document these elements as software patterns. This is not a matter of documenting the solution and problem surrounding each element; this material is already evident in most papers and books. We need to go deeper to understand the forces and context of the problems that give rise to the proposed solutions. These are the undocumented and often misunderstood features of software elements that need to be elaborated on before they can be incorporated into a system and enter into the mainstream of software engineering and business applications.

Because many people are still not familiar with software patterns, and those who are often think of them as just problem-and-solution pairs, I'll provide a quick review of the two. Software patterns have their roots in Christopher Alexander's work in the field of building architecture. After reading his work, it was clear to software engineers that, like building designs, there are many recurring problems and solutions used in the design of software systems. Unfortunately, these combinations were hard to find, except in the minds of the most experienced developers. Moreover, knowing the problem and the solution was not enough. Software engineers needed to know when the solutions were appropriate for the given problems.

Alexander proposed the following definition for a pattern:
* A three-part rule that expresses a relation between a certain context, a problem and a solution.
* As an element in the world, each pattern is a relationship between a certain context, a certain system of forces that occurs repeatedly in that context, and a certain spatial configuration that allows these forces to resolve themselves.
* As an element of language, a pattern is an instruction that shows how the spatial configuration can be used, repeatedly, to resolve the given system of forces, wherever the context makes it relevant.
* The pattern is, in short, at the same time a thing, which happens in the world, and the rule that tells us how to create that thing and when we must create it. It is both a process and a thing, a description of a thing that is alive, and a description of the process that will generate the thing.

Although there are many different pattern formats, the minimal format contains the following headings or others that deal with similar subject matter.

Name: As the saying goes in the object-oriented community, a good variable name is worth a thousand words, and a good pattern name, although it is just a short phrase, should contain more information than just its number of words would suggest. Would the word ''agent'' be a good pattern name? Although it means a lot more than the single word suggests, it has too many meanings. One should strive for a short phrase that still says it all.

Problem: A precise statement of the problem to be solved. Think of the perspective of a software engineer asking himself, ''How do I ... ?'' A good problem for a pattern is one that software engineers will ask themselves often.

Context: A description of a situation when the pattern might apply. However, in itself, the context does not provide the only determining factor as to situations in which the pattern should be applied. Every pattern will have a number of forces that needs to be balanced before applying the pattern. The context helps one determine the impact of the forces.

Forces: A description of an item that influences the decision as to when to apply the pattern in a context. As Jim Coplien said, ''Forces can be thought of as items that push or pull the problem towards different solutions or that indicate trade-offs that might be made.''

Solution: A description of the solution in the context that balances the forces.

Other sections such as resulting context, rationale, known uses, related patterns and implementation with sample code are usually included to help with the pattern's description.

A good pattern provides more than just the details of these sections; it should also be generative. Patterns are not solutions; rather, patterns generate solutions. You take your design problem and look for a pattern to apply to create the solution. The greater the potential for the application of a pattern, the more generative it is. Although very specific patterns are of use, a great pattern has many applications. For this to happen, pattern writers spend considerable time and effort attempting to understand all aspects of their patterns and the relationships between them.

Although they are useful for solving specific design problems, one can enhance the generative quality of patterns by assembling related ones and then positioning them among one another to form a pattern language that enables us to use them to build systems. Forcing each pattern to identify its position within the space of existing patterns is not only good practice, it is good research. All patterns should be part of a pattern language. It is not only helpful to you, but to all those other software engineers who will use the patterns to develop their systems in the future.

I constantly ask myself ''Am I pushing patterns because I am a 'pattern' person, or is there a greater benefit other than my own personal satisfaction in getting someone else hooked on them?'' I believe it's a good question to ask, because it requires the support of non-pattern people to introduce patterns into an organization. Many developers will never write a single pattern, read one of the many pattern books available or attend a Pattern Languages of Programs conference. These people need to be convinced of the merits of patterns before they will ever use them.

My argument to these people is based on information that I find missing from many Java books, lectures and developers' general knowledge. First, they either don't or can't describe the forces of a given solution to a problem in a context. Second, they don't describe the relationships between these entities -- such as which loop construct, collection class or design is best used in a given situation. Patterns and pattern languages are good ways to ensure that all programming elements are discussed and related to one another.

Why not add them to a book, a course and to your discussions? Many have. If you haven't done so already, check out http://java.sun.com/blueprints/corej2eepatterns/index.html. Deepak Alur, John Crupi and Dan Malks have done an excellent job of writing patterns that you can use in the context of designing J2EE applications. Do their patterns represent the definitive set? Absolutely not. As developers gain more experience, new patterns will be detected and others will be rewritten. Software development is expensive and there is no benefit in having developers learn everything from scratch all the time. Therefore, there is no better time than now to introduce yourself and your colleagues to patterns, and to write some new ones if you can. Join the pattern club; you will be glad you did.