July 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

What Are Design Patterns?

  • March 12, 2004
  • By James W. Cooper
  • Send Email »
  • More Articles »

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.

  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 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 Design Patterns.

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.



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel