Midrange Programmer

It is extremely rare to write a unique software application, one that uses completely original techniques and algorithms. Sure, the problems we software developers solve on a daily basis are unique, but the techniques and algorithms we use to solve those problems are not. Design patterns attempt to catalog and describe solutions to common application design problems. There are several popular forms of design patterns; what differentiates one from another is the format used to describe them, which typically includes a software problem, its solutions, its consequences, and other information.

Work on software design patterns began in the late 1980s with the adaptation of concepts that were developed by Christopher Alexander to address challenges related to civil engineering. Software design patterns continued to evolve in academic circles and gained widespread recognition with the publication in 1994 of Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The authors are frequently referred to as the GoF, or Gang of Four. Today, there are dozens of good books and quite a few Web sites dedicated to the pursuit of better software design using design patterns.

Design patterns are generally associated with object-oriented software design but are general enough to be useful to programmers using just about any programming language. In fact, the first time I consciously used design patterns was during the development of an RPG IV application. That application provided a simplified interface to AS/400 message APIs. I used the Façade design pattern, described by the GoF as "a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use." Using a design pattern helped me to understand the goals and trade-offs of using a Façade instead of another similar design pattern, like Adapter or Bridge.

Design patterns provide a catalog of solutions you can consult during the design phase of a software project. You use that catalog to locate, compare, and contrast options, as well as to identify the potential pitfalls associated with a particular software solution. Understanding such information during the design phase helps you to select the best solution and avoid costly modifications later.

Design patterns are particularly useful to programmers who are new to object-oriented program design. Faced with an overwhelming number of design options, it is easy to fall back on procedural design techniques. Without a mentor or object-oriented blueprint to follow, it is difficult to narrow down choices and to understand the consequence of those choices. Design patterns synthesize the work of others and provide a virtual mentor and set of object-oriented blueprints for common software design problems.

Every software developer has been the new person at least once, having to fix software he does not understand and work with new people who describe that software using unfamiliar terminology. The developer is expected to understand complex interactions between a project's various software applications. But wouldn't it be nice if there were a universal way of describing software applications using a common vocabulary, common design goals, and recognized software interactions? Design patterns provide that universal description.

When someone tells me that a Java program uses an Abstract Factory to build messages and that the actual (concrete) message factory is a Singleton, I know a lot about the code. I know, for example, that there is only one message factory, providing messages that conform to a standard interface. I also know that my code will work with the abstract definitions of the factory and messages. So what does this buy me? I can look at the consequences associated with Abstract Factories and Singletons and, among other things, learn that an Abstract Factory makes it easy to exchange one factory for another without changing client code. The consequences also warn that extending an Abstract Factory to produce new products is difficult because this usually entails a change to the Abstract Factory interface, the Abstract Factory class, and all of its subclasses.

Design patterns use a template to describe common software patterns. There are quite a few pattern variations, but the GoF, CORBA (Common Object Request Broker Architecture), mini, micro, and anti patterns are among the most common. Every design pattern variation comes with its own template, but nearly all design pattern templates share some common traits, like a name, a problem description, a solution, and a description of consequences.

Without a template, there can be no design pattern. Although you could describe a program construct in object-oriented terms without a template, that description would lack the structure necessary to compare it with other options. Taking the time to use a template helps to ensure that the design pattern will be useful and not merely a statement of fact, like, "This is the blowhard design pattern, which is useful because I am an expert in such things, and I say it is."

Design patterns, which are usually combined in a book or some other format, become a catalog that programmers can refer to when designing software. Popular software components like the Java Foundation Class library incorporate design pattern principles and naming for the class files used in their architecture. Understanding the underlying design patterns used by these components makes it easier to develop an understanding of Java Foundation Class components.

There are quite a few types of design patterns. Each design pattern has a template, which describes the design pattern. The GoF pattern template, for example, takes the following form:

This is the template used for every GoF pattern. In general, the GoF patterns describe interactions among objects. Other design patterns, like the mini and micro patterns, have their own template. Mini and micro patterns deal with single objects and help describe design problems that solve specific problems, like how you would sort a collection, or what type of collection you should use to support an object lookup.

The pyramid in Figure 1 shows how design patterns fit with other application design considerations, like corporate infrastructures and standards. Micro and mini patterns describe classes and, occasionally, toolkits. Moving down the pyramid, you can see that design patterns describe interactions among applications and frameworks. Corporate infrastructures and standards provide the base, describing interactions between enterprise systems and external standards-based systems.

Anti patterns are another popular form of design pattern. An anti pattern describes common application development and design mistakes and helps developers avoid or correct those mistakes. What I have found most valuable about anti patterns is that they help you to quickly understand and avoid the traps and pitfalls that programmers with a procedural programming background inevitably fall into as they begin object-oriented programming. One of those traps is the Blob anti pattern. This anti pattern, which is also referred to as the Winnebago or God class, combines too much processing into a single class.

To begin using design patterns, you need to have at least a basic understanding of object-oriented concepts. The following terms are frequently used to describe design patterns:

Understanding this short list of terms and their definitions will help you use design patterns. Once you are comfortable with the concepts, you are ready to start using design patterns while designing your applications. The first step is to understand the patterns that fit your needs. Next, you should study the structure, participants, and collaborations of those patterns. (In Java, this means understanding the classes and objects in patterns and how they relate to one another.) After determining which pattern is the best fit, choose names given by the pattern for your application that reflect the pattern participants and operations. For example, you might name an RPG IV procedure that uses the Memento pattern to support an undo function for order changes OrderMementoStack.

Anti patterns describe common problems in object-oriented programs. Many of those problems are the result of programmers applying procedural solutions to object-oriented designs. Understanding what those problems are and how to avoid making them helps programmers with experience in procedural programming languages, like RPG, transition to object-oriented languages, like Java. Anti patterns help you not only to avoid mistakes but also to fix them, by describing how to refactor code.

Using anti patterns requires some tact and understanding. We all learn from mistakes, but nobody wants to be singled out as the anti pattern poster child. Setting standards and regularly reviewing code before you have a problem is a good idea. Photocopying an anti pattern and slipping it in a coworker's desk drawer is not.

There are quite a few Web sites, books, articles, forums, conferences, and papers on design patterns. To further your education on patterns, you'll need to buy some books. The GoF book is a good starting point, the first section of which describes, in very clear terms, many aspects of object-oriented design, including white box reuse, black box reuse, parameterized types, and polymorphism. The last sections provide a detailed description of 23 design patterns.

After reading the GoF book, you will likely find it useful to start reading books that describe pattern implementation in a particular programming language or solution space, or that cover related topics like anti patterns. Books on anti patterns, like AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis or Bitter Java, blend humor, tact, and experience to help you avoid problems and steer projects clear of object-oriented hazards.

The Internet is also a good source of information on design patterns. Searching for "GoF design patterns" on Google listed over 9,000 sites. There are Web forums dedicated to patterns on the jGuru and Sun Microsystems Web sites.

I hope this brief introduction has piqued your interest in design patterns. Although design patterns target object-oriented design, they are also useful when designing object-based systems written in RPG IV or almost any other programming language. Developing an understanding of design patterns can help you build better software by helping you quickly understand design options and their consequences. Design patterns also give you a common vocabulary and understanding of software components, which is useful when working with a team. Understanding and applying design patterns in your applications will take time, but the benefits start to accumulate quickly. If you have not done so already, I encourage you to look into design patterns to understand how they can help you build better applications.

David Morris is a software architect at Plum Creek Timber Company and started the iSeries-toolkit open-source project. He can be reached at dmmorris@itjungle.com.