What Are Design Patterns?
Sitting at your desk in front of your workstation, you stare into space, trying to figure out how to write a new program feature. You know intuitively what must be done, what data and what objects come into play, but you have this underlying feeling that there is a more elegant and general way to write this program.
In fact, you probably don't write any code until you can build a picture in your mind of what the code does and how the pieces of the code interact. The more that you can picture this "organic whole," or gestalt, the more likely you are to feel comfortable that you have developed the best solution to the problem. If you don't grasp this whole right away, you may keep staring out the window for a time, even though the basic solution to the problem is quite obvious.
In one sense you feel that the more elegant solution will be more reusable and more maintainable, but even if you are the sole likely programmer, you feel reassured once you have designed a solution that is relatively elegant and that doesn't expose too many internal inelegancies.
One of the main reasons that computer science researchers began to recognize design patterns is to satisfy this need for elegant, but simple, reusable solutions. The term design patterns sounds a bit formal to the uninitiated and can be somewhat offputting when you first encounter it. But, in fact, design patterns are just convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is simple: write down and catalog common interactions between objects that programmers have frequently found useful.
One of the frequently cited patterns from early literature on programming frameworks is the Model-View-Controller framework for Smalltalk (Krasner and Pope 1988), which divided the user interface problem into three parts, as shown in Figure 1-1. The parts were referred to as a data model, which contains the computational parts of the program; the view, which presented the user interface; and the controller, which interacted between the user and the view.
Figure 1-1 The Model-View-Controller framework
Each of these aspects of the problem is a separate object, and each has its own rules for managing its data. Communication among the user, the GUI, and the data should be carefully controlled, and this separation of functions accomplished that very nicely. Three objects talking to each other using this restrained set of connections is an example of a powerful design pattern.
In other words, design patterns describe how objects communicate without become entangled in each other's data models and methods. Keeping this separation has always been an objective of good OO programming, and if you have been trying to keep objects minding their own business, you are probably using some of the common design patterns already.
Design patterns began to be recognized more formally in the early 1990s by Eric Gamma (1992), who described patterns incorporated in the GUI application framework, ET++. The culmination of these discussions and a number of technical meetings was the publication of the parent book in this series, Design Patterns: Elements of Reusable Software, by Gamma et al. (1995). This book, commonly referred to as the "Gang of Four," or "GoF," book, has had a powerful impact on those seeking to understand how to use design patterns and has become an all-time bestseller. It describes 23 commonly occurring and generally useful patterns and comments on how and when you might apply them. We will refer to this groundbreaking book as Design Patterns throughout this book.
Since the publication of the original Design Patterns text, there have been a number of other useful books published. One closely related book is The Design Patterns Smalltalk Companion (Alpert, Brown, and Woolf 1998), which covers the same 23 patterns from the Smalltalk point of view. We'll refer to this book throughout as the Smalltalk Companion. Finally, we recently published Java Design Patterns: A Tutorial and Visual Basic Design Patterns: VB6 and VB.NET, which illustrate all of these patterns in those languages (Cooper 2000, 2002).
Defining Design Patterns
We all talk about the way we do things in our jobs, hobbies, and home life, and we recognize repeating patterns all the time.
- Sticky buns are like dinner rolls, but I add brown sugar and nut filling to them.
- Her front garden is like mine, but I grow astilbe in my garden.
- This end table is constructed like that one, but in this one, there are doors instead of drawers.
We see the same thing in programming when we tell a colleague how we accomplished a tricky bit of programming so he doesn't have to recreate it from scratch. We simply recognize effective ways for objects to communicate while maintaining their own separate existences.
Some useful definitions of design patterns have emerged as the literature in this field has expanded.
- Design patterns are recurring solutions to design problems you see over and over. (The Smalltalk Companion)
- Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development. (Pree 1995)
- Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design and implementation. (Coplien and Schmidt 1995)
- A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. (Buschmann et al. 1996)
- Patterns identify and specify abstractions that are above the level of single classes and instances or of components. (Gamma, Johnson, and Vlissides, 1993)