Quality programming is not as common as it should be. All too often, applications are hacked out that, while able to meet business requirements, contain code that is overly complex, difficult to maintain, and, the most evil of all, unable to adapt. So how is it that some code gets that “quality” label? If a group of computer scientists were to cut a dozen quality applications apart, they would find common characteristics: a simple design based on well-crafted data structures and common algorithms. Until recently, the authors of quality applications were coders who carried with them war bags full of techniques garnered from decades of experience. They can gain a difficult programming situation, see a problem that is similar to one that they’ve solved, and quickly code a simple and elegant solution.

So how do you go about filling your own war bag? Do you have to work another decade or so and hope to get the experience for solving reoccurring business problems? No. Thankfully, techniques are becoming documented using a strategy known as design patterns.

A Pattern for Design Patterns

In 1994, Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides was published. It is required reading for anyone who wants to increase his chances of designing quality software. Gamma, Helm, Johnson, and Vlissides’ book has become so well-known that they now have a nickname: “Gang of Four” or GoF.

Design Patterns lists 23 patterns, but the GoF did more than just provide a couple of dozen patterns: They created a standard strategy for describing a design pattern. They wanted industry experts to follow their lead and add to the expanding war bag of design patterns. The GoF’s strategy was constructed so that industry experts could add design patterns by documenting them by creating descriptions the have the following standard sections: Intent, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns.

There are a number of books available that follow the GoF’s strategy (such as Analysis Patterns: Reusable Object Models by Martin Fowler). You should be looking for more books on design patterns that have been explicitly written for e-business applications. I happen to know that IBM Press is currently working on one such book.

Example Uses

Please realize that the use of design patterns does not require the use of an OO language. David Morris has authored several articles for Midrange Computing that show example uses of a couple of the GoF’s design patterns with an RPG application, including “RPG Building Blocks: ILE Message Handling” (November 1998).

The opportunity to use design patterns presents itself during analysis. (See “The Business Case for Use Cases” [September 2000]). In object-oriented analysis, the designers create class models to represent the business entities described in use cases. Based on a general familiarity with the ever-increasing set of design patterns, the designer looks for the opportunity to improve his object design with well-known design patterns.

I’ve used the following patterns from the GoF’s book: Command, Façade, Singleton, Bridge, Factory, and Adapter. The Command pattern works great for simple interactive Web applications. I used Façade to simplify the interface of a complex set of Java classes. Singleton worked well when I wanted to cut down the number of SQL connections to one per application. I used Bridge to create a Java class that created a common interface for both IBM’s and ASNA’s record-level access classes. I used Factory for a distributed application that used Java’s Remote Method Invocation (RMI). To be able to use RMI, you need to develop a server application that generates Java objects on command, which is where I used the Factory pattern. And, I used Adapter to write a simple set of Java classes the wrappered (albeit, not completely) IBM’s Java Toolbox for the AS/400’s data queue classes with Sun Microsystems’ Java 2 Platform, Enterprise Edition (J2EE) Java Message Service (JMS) API.

The Finder Pattern

The best place to get started with design patterns is Design Patterns. The book uses C++ in its sample code. The samples are fairly easy to follow if you know a bit of C or C++, but you may opt for James Cooper’s Java Design Patterns: A Tutorial or Mark Grand’s Patterns in Java: Volume 1, A Catalog of Reusable Design Patterns Illustrated with UML. I feel, however, that the original Design Patterns is still the best text on the subject, so you should have a copy handy in your shop. As always, the Web is the quickest way to get started, so try the Patterns home page at http://hillside.net/patterns/. The Patterns home page contains information on pattern books, articles, conferences, research projects, mailing lists, study groups, and most anything else concerning the worldwide pattern community. The use of design patterns has become so widespread that many shops now expect applicants to be familiar with, at the very least, the patterns described in Design Patterns. And so should you.

REFERENCES AND RELATED MATERIALS

• “Developing Java Solutions Using Design Patterns,” Kelby Zorgdrager (online article available at www.developer.ibm.com/library/articles/programmer/kelby1.html)

• IBM Research Design Patterns Web page: www.research.ibm.com/ designpatterns/relatedsites.htm