Design patterns, the big picture, Part 1: Design pattern history and classification

Understanding the concept and use of design patterns in software development

Design patterns are a cornerstone of modern software development. Using them can improve the maintainability of your Java applications and help you accomplish other tasks more effectively. Jeff Friesen's three-part introduction to design patterns takes a wide-angle view, from the GoF patterns to design patterns used in interaction design, team organization, and more. Part 1 introduces the concept and use of design patterns, offers some design pattern history and trivia, and ends with a listing of software design patterns by classification. Included with this article is a complete index of design pattern tutorials on JavaWorld.

Numerous strategies have been devised to simplify and reduce the costs of designing software, especially in the area of maintenance. Learning how to identify and work with reusable software components (occasionally referred to as software integrated circuits) is one strategy. Using design patterns is another.

This article launches a three-part series on design patterns. In this part I'll introduce the conceptual framework of design patterns and walk through a demonstration of evaluating a design pattern for a particular use case. I'll also discuss the history of design patterns, including some interesting trivia. Finally, I'll classify and summarize the most-used software design patterns that have been discovered and documented through the past couple of decades.

What is a design pattern?

Designing reusable object-oriented software that models an existing system is genuinely challenging. A software developer must factor the system's entities into classes whose public interfaces aren't overly complex, establish relationships among classes, expose inheritance hierarchies, and more. Because most software remains in use long after it was written, software developers also need to address current application requirements while keeping their code and infrastructure flexible enough to meet future needs.

Experienced object-oriented developers have discovered that software design patterns facilitate the coding of stable and robust software systems. Reusing these design patterns rather than constantly developing new solutions from scratch is efficient, and it reduces some of the risk of error. Every design pattern identifies a recurring design problem in a specific application context, then offers a generalized, reusable solution that is applicable to different application scenarios.

"A design pattern describes the classes and interacting objects used to solve a general design problem in a specific context."

Some developers define a design pattern as a class-encoded entity (such as a linked list or bit vector), whereas others say that a design pattern is in the entire application or subsystem. My view is that a design pattern describes the classes and interacting objects used to solve a general design problem in a specific context. More formally, a design pattern is specified as a description that consists of four basic elements:

  1. A name that describes the design pattern and gives us a vocabulary for discussing it
  2. A problem that identifies the design problem needing to be solved along with the context in which the problem occurs
  3. A solution to the problem, which (in a software design pattern context) should identify the classes and objects that contribute to the design along with their relationships and other factors
  4. An explanation of the consequences of using the design pattern

In order to identify the appropriate design pattern to use, you must first clearly identify the problem that you're trying to solve; that's where the problem element of the design pattern description is helpful. Choosing one design pattern over another also usually involves trade-offs that can impact an application's or system's flexibility and future maintenance. That's why it's important to understand the consequences of using a given design pattern before you begin implementing it.

Evaluating a design pattern

Consider the task of designing a complex user interface using buttons, textfields, and other non-container components. The Composite design pattern regards containers as components, which lets us nest containers and their components (containers and non-containers) within other containers, and do so recursively. If we chose not to use the Composite pattern we would have to create many specialized non-container components (a single component combining a password textfield and a login button, for example), which is harder to achieve.

Having thought this through, we understand the problem we're trying to solve and the solution offered by the Composite pattern. But what are the consequences of using this pattern?

Using Composite means that your class hierarchies will mix container and non-container components. Simpler clients will treat container and non-container components uniformly. And it will be easier to introduce new kinds of components into the UI. Composite can also lead to overly generalized designs, making it harder to restrict the kinds of components that can be added to a container. Since you won't be able to rely on the compiler to enforce type constraints, you will have to use runtime type checks.

What's wrong with runtime type checks?

Runtime type checks involve if statements and the instanceof operator, which leads to brittle code. If you forget to update a runtime type check as your application requirements evolve, you could subsequently introduce bugs.

It is also possible to choose an appropriate design pattern and use it incorrectly. The Double-Checked locking pattern is a classic example. Double-checked locking reduces lock acquisition overhead by first testing a locking criterion without actually acquiring the lock, and then only acquiring the lock if the check indicates that locking is required. While it looked good on paper, Double-checked locking in JDK 1.4 had some hidden complexities. When JDK 5 extended the semantics of the volatile keyword, developers were finally able to reap the benefits of the Double-checked locking pattern.

More about Double-checked locking

See "Double-checked locking: Clever, but broken" and "Can double-checked locking be fixed?" (Brian Goetz, JavaWorld) to learn more about why this pattern didn't work in JDK 1.4 and earlier. For more about specifying DCL in JDK 5 and later, see "The 'Double-Checked Locking is Broken' Declaration" (University of Maryland Department of Computer Science, David Bacon, et al.).

Anti-patterns

When a design pattern is commonly used but is ineffective and/or counterproductive, the design pattern is known as an anti-pattern. One might argue that Double-checked locking as used in JDK 1.4 and earlier was an anti-pattern. I would say that it was merely a bad idea in that context. For a bad idea to evolve into an anti-pattern, the following conditions must be met (see Resources).

  • A repeated pattern of action, process, or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results.
  • An alternative solution exists that is clearly documented, proven in practice, and repeatable.

While Double-checked locking in JDK 1.4 did meet the first requirement of an anti-pattern, it did not meet the second: although you could use synchronized to solve the problem of lazy initialization in a multithreaded environment, doing so would have defeated the reason for using Double-checked locking in the first place.

Deadlock anti-patterns

Recognizing anti-patterns is a prerequisite to avoiding them. Read Obi Ezechukwu's three-part series for an introduction to three anti-patterns famous for causing deadlock:

Design pattern history

Design patterns date back to the late 1970s with the publication of A Pattern Language: Towns, Buildings, Construction by architect Christopher Alexander and a few others. This book introduced design patterns in an architectural context, presenting 253 patterns that collectively formed what the authors called a pattern language.

The irony of design patterns

Although design patterns used for software design trace their beginning to A Pattern Language, this architectural work was influenced by the then-emerging language to describe computer programming and design.

The concept of a pattern language subsequently emerged in Donald Norman's and Stephen Draper's User Centered System Design, which was published in 1986. This book suggested the application of pattern languages to interaction design, which is the practice of designing interactive digital products, environments, systems, and services for human use.

Meanwhile, Kent Beck and Ward Cunningham had begun to study patterns and their applicability to software design. In 1987, they used a series of design pattern to assist Tektronix's Semiconductor Test Systems Group, which was having trouble finishing a design project. Beck and Cunningham followed Alexander's advice for user-centered design (letting representatives of the project's users determine the design outcome) while also providing them with some design patterns to make the job easier.

Erich Gamma also realized the importance of recurring design patterns while working on his PhD thesis. He believed that design patterns could facilitate the task of writing reusable object-oriented software, and pondered how to document and communicate them effectively. Prior to the 1991 European Conference on Object-Oriented Programming, Gamma and Richard Helm started to catalog patterns.

At an OOPSLA workshop held in 1991, Gamma and Helm were joined by Ralph Johnson and John Vlissides. This Gang of Four (GoF), as they subsequently were known, went on to write the popular Design Patterns: Elements of Reusable Object-Oriented Software, which documents 23 design patterns in three categories.

The modern evolution of design patterns

Design patterns have continued to evolve since the original GoF book, especially as software developers have confronted new challenges related to changing hardware and application requirements.

In 1994, a U.S.-based non-profit organization known as the Hillside Group inaugurated Pattern Languages of Programs, a group of annual conferences whose aim is to develop and refine the art of software design patterns. These ongoing conferences have yielded many examples of domain-specific design patterns. For example, design patterns in a concurrency context.

Christopher Alexander at OOPSLA

OOPSLA 96's keynote address was delivered by the architect Christopher Alexander.Alexander reflected on his work and on how the object-oriented programming community had hit and missed the mark in adopting and adapting his ideas about pattern languages to software. You can read Alexander's address in full: "The Origins of Pattern Theory: the Future of the Theory, And The Generation of a Living World."

In 1998 Mark Grand released Patterns in Java. This book included design patterns not found in the GoF book, including concurrency patterns. Grand also used the Unified Modeling Language (UML) to describe design patterns and their solutions. The book's examples were expressed and described in the Java language.

Software design patterns by classification

Modern software design patterns are broadly classified into four categories based on their use: creational, structural, behavioral, and concurrency. I'll discuss each category and then list and describe some of the prominent patterns for each one.

Other types of design patterns

If you're thinking that there are more types of patterns, you are right. A later article in this series will discuss additional design pattern types: lnteraction, architectural, organizational, and communication/presentation patterns.

Creational patterns

A creational pattern abstracts the process of instantiation, separating how objects are created, composed, and represented from the code that relies on them. Class creational patterns use inheritance to vary the classes that are instantiated, and object creational patterns delegate instantiation to other objects.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more