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)
But while it is helpful to draw analogies to architecture, cabinetmaking, and logic, design patterns are not just about the design of objects but about the interaction between objects. One possible view of some of these patterns is to consider them as communication patterns.
Some other patterns deal not just with object communication but with strategies for object inheritance and containment. It is the design of simple, but elegant, methods of interaction that makes many design patterns so important.
Design patterns can exist at many levels from very low-level, specific solutions to broadly generalized system issues. There are now hundreds of patterns in the literature. They have been discussed in articles and at conferences of all levels of granularity. Some are examples that apply widely, and a few writers have ascribed pattern behavior to class groupings that apply to just a single problem (Kurata 1998).
It has become apparent that you don’t just write a design pattern off the top of your head. In fact, most such patterns are discovered rather than written. The process of looking for these patterns is called “pattern mining,” and it is worthy of a book of its own.
The 23 design patterns covered in the original Design Patterns book had several known applications and were on a middle level of generality, where they could easily cross application areas and encompass several objects.
The authors divided these patterns into three types: creational, structural, and behavioral.
- Creational patterns create objects for you rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
- Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.
- Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.
We’ll be looking at C# versions of these patterns in the chapters that follow, and we will provide at least one complete C# program for each of the 23 patterns. This way you can examine the code snippets provided and also run, edit, and modify the complete working programs on the accompanying CD-ROM. You’ll find a list of all the programs on the CD-ROM at the end of each pattern description.
The Learning Process
We have found that, regardless of the language, learning design patterns is a three-step process.
First, you accept the premise that design patterns are important in your work. Then, you recognize that you need to read about design patterns so you will know when you need them. Finally, you internalize the patterns in sufficient detail that you know which ones might help you solve a given design problem.
For some lucky people, design patterns are obvious tools, and these people can grasp their essential utility just by reading summaries of the patterns. For many of the rest of us, there is a slow induction period after we’ve read about a pattern followed by the proverbial “Aha!” when we see how we can apply them in our work. This book takes you to that final stage of internalization by providing complete, working programs that you can try out yourself.
The examples in Design Patterns are brief and are in C++ or, in some cases, Smalltalk. If you are working in another language, it is helpful to have the pattern examples in your language of choice. This book attempts to fill that need for C# programmers.
Studying Design Patterns
There are several alternate ways to become familiar with these patterns. In each approach, you should read this book and the parent Design Patterns book in one order or the other. We also strongly urge you to read the Smalltalk Companion for completeness, since it provides alternative descriptions of each of the patterns. Finally, there are a number of Web sites for you to peruse on learning and discussing design patterns.
Notes on Object-Oriented Approaches
The fundamental reason for using design patterns is to keep classes separated and prevent them from having to know too much about one another. Equally important, using these patterns helps you avoid reinventing the wheel and allows you to describe your programming approach succinctly in terms other programmers can easily understand.
There are a number of strategies that OO programmers use to achieve this separation, among them encapsulation and inheritance. Nearly all languages that have OO capabilities support inheritance. A class that inherits from a parent class has access to all of the methods of that parent class and to all of its nonprivate variables. However, by starting your inheritance hierarchy with a complete, working class, you may be unduly restricting yourself as well as carrying along specific method implementation baggage. Instead, Design Patterns suggests that you always do the following.
Program to an interface and not to an implementation.
Putting this more succinctly, you should define the top of any class hierarchy with an abstract class or an interface, which implements no methods but simply defines the methods that class will support. Then in all of your derived classes you have more freedom to implement these methods as most suits your purposes.
The other major concept you should recognize is that of object composition. This is simply the construction of objects that contain others: encapsulation of several objects inside another one. While many beginning OO programmers use inheritance to solve every problem, as you begin to write more elaborate programs, you will begin to appreciate the merits of object composition.Your new object can have the interface that is best for what you want to accomplish without having all the methods of the parent classes. Thus, this is the second major precept suggested by
Favor object composition over inheritance.
About the Author
James W. Cooper is a research staff member in the Advanced Information Retrieval and Analysis Department at the IBM Thomas J. Watson Research Center. He is also a columnist for Java Pro magazine and a reviewer for Visual Basic Programmer’s Journal. He has published 14 books, which include C# Patterns, published by Addison Wesley.