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, and anti-patterns. 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.
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:
- A name that describes the design pattern and gives us a vocabulary for discussing it
- A problem that identifies the design problem needing to be solved along with the context in which the problem occurs
- 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
- 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 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.
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.
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.
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 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.
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.
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.
- : This pattern provides an interface to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.
- : Separates the construction of a complex object from its representation, enabling the same construction process to create various representations. Abstracting the steps of object construction allows different implementations of the steps to construct different representations of the objects.
- : Defines an interface for creating an object, but lets subclasses decide which class to instantiate. This pattern lets a class defer instantiation to subclasses. is a related pattern. (See Resources.)
- Lazy initialization: This pattern gives us a way to delay object creation, database lookup, or another expensive process until the first time the result is needed.
- Multiton: Expands on the singleton concept to manage a map of named class instances as key-value pairs, and provides a global point of access to them.
- : Keep a set of initialized objects ready to use, rather than be allocated and destroyed on demand. The intent is to avoid expensive resource acquisition and reclamation by recycling objects that are no longer in use.
- Prototype: Specifies the kinds of objects to create using a prototypical instance, then create new objects by copying this prototype. The prototypical instance is cloned to generate new objects.
- Resource acquisition is initialization: This pattern ensures that resources are automatically and properly initialized and reclaimed by tying them to the lifespan of suitable objects. Resources are acquired during object initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in the case of errors.
- : Ensures that a class has only one instance and provides a global point of access to this instance.