What are Design Patterns

1. 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 objectoriented 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. View Controller Data Model 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 Erich 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, Helm, Johnson, and Vlissides (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, which illustrate all of these patterns in those languages. 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 1994) • “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 et al., 1993) But while it is helpful to draw analogies to architecture, cabinet making, 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 selected for inclusion in the original Design Patterns book were those that had several known applications and that 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 yo u can examine the code snippets we provide 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 CDROM at the end of each pattern description. The Learning Process We have found that regardless of the language, learning design patterns is a multiple-step process. 1. Acceptance 2. Recognition 3. Internalization First, you accept the premise that design patterns are important in your work. Then, you recognize that you need to read about design patterns in order to know when you might use 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 helps to take you to that final stage of internalization by providing complete, working programs that you can try out for 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 on learning and discussing design patterns for you to peruse. 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. It also has access 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 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. And since C#6 only supports interfaces and does not support inheritance, this is obviously very good advice in the C# context. 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, the second major precept suggested by Design Patterns is Favor object composition over inheritance. C# Design Patterns Each of the 23 patterns in Design Patterns is discussed, at least one working program example for that pattern is supplied. All of the programs have some sort of visual interface to make them that much more immediate to you. All of them also use class, interfaces, and object composition, but the programs themselves are of necessity quite simple so that the coding doesn’t obscure the fundamental elegance of the patterns we are describing. However, even though C# is our target language, this isn’t specifically a book on the C# language. There are lots of features in C# that we don’t cover, but we do cover most of what is central to C#. You will find, however, that this is a fairly useful tutorial in object-oriented programming in C# and provides good overview of how to program in C#.NET. How This Book Is Organized We take up each of the 23 patterns, grouped into the general categories of creational, structural, and behavioral patterns. Many of the patterns stand more or less independently, but we do take advantage of already discussed patterns from time to time. For example, we use the Factory and Command patterns extensively after introducing them, and we use the Mediator pattern several times after we introduce it. We use the Memento again in the State pattern, the Chain of Responsibility in the Interpreter pattern discussion, and the Singleton pattern in the Flyweight pattern discussion. In no case do we use a pattern before we have introduced it formally. We also take some advantage of the sophistication of later patterns to introduce new features of C#. For example, the Listbox, DataGrid, and TreeView are introduced in the Adapter and Bridge patterns. We show how to paint graphics objects in the Abstract Factory, We introduce the Enumeration interface in the Iterator and in the Composite, where we also take up formatting. We use exceptions in the Singleton pattern and discuss ADO.NET database connections in the Façade pattern. And we show how to use C# timers in the Proxy pattern. The overall .NET system is designed for fairly elaborate web-based clientserver interactions. However, in this book, concentrate on object-oriented programming issues in general rather than how to write Web-based systems. We cover the core issues of C# programming and show simple examples of how Design Patterns can help write better programs.