Home > Articles > Software Development & Management

A Look Back: Why We Wrote Design Patterns: Elements of Reusable Object-Oriented Software

Toggle Open Article Table of ContentsArticle Contents

Close Table of ContentsArticle Contents

  1. 'Design Patterns: Elements of Reusable Object-Oriented Software
Close Table of Contents
  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
Close Window

Erich GammaRichard HelmRalph JohnsonJohn M. Vlissides

Learn more…

Sorry, this author hasn't written any articles.

Sorry, this author doesn't have anything for sale.

Sorry, this author hasn't posted any blogs.

On the 15th anniversary of the publication of the Gang of Four's Design Patterns, we are revisiting this article written in 1994 for Addison-Wesley's Innovations newsletter, in which Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides made the case for the book on the eve of its debut.

Designing object-oriented software is hard—designing reusable object-oriented software is even harder. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult, if not impossible, to get "right" the first time, and that multiple attempts at reuse with subsequent redesigns are normal.

Yet experience has shown that many object-oriented systems exhibit idiomatic and recurring patterns and structures—objects that solve particular design problems and make designs more flexible, elegant, and ultimately reusable. The Model-View-Controller (MVC) idiom found in Smalltalk is a design that separates representation defined by a Model from possible screen presentations defined by Views. Model-View-Controller is applied widely throughout Smalltalk systems.

These recurring design structures or patterns of design have a positive impact on object-oriented design and development. They help designers reuse successful designs and architectures based on prior experiences. A designer who is familiar with a set of design patterns can apply them immediately to design problems without having to rediscover the design solutions. This design experience is somewhat similar to that of architects or engineers who design buildings. Just as they may follow certain standard designs for buildings (skyscrapers with a solid core and hanging glass wall, energy efficient solar house) or bridges (suspension, cantilever, truss), so do object-oriented designers follow patterns like "represent states with objects" and "use wrappers to flexibly add/remove features from objects." Once you have the pattern, many design decisions follow.

This design experience is valuable. What is often missing, especially in software, is a record of this experience for others to use. How many times have you had that feeling, "I have solved this problem before in a previous design"? Of course, we all have had cases of design "deja-vu." If only we knew about the existing experience, the design issues, and the previously discovered solutions beforehand!

Our main goal in writing Design Patterns was recording the experience of designing reusable object-oriented software. We set out to systematically name, explain, evaluate, and catalog the commonly occurring important design patterns found in object-oriented systems. We try to capture in one place the wealth of experience about the design of reusable object-oriented software in a form that provides a ready reference for designers of object-oriented systems.

Central to Design Patterns is the catalog of 23 design patterns. The patterns described fall into three broad categories: creational patterns that concern the instantiation of objects, structural patterns that concern how objects and classes stand in relationship to each other, and behavioral patterns that concern the distribution of behavior and responsibilities across classes and objects.

Each description of a design pattern names, abstracts, and identifies the key aspects of a common and recurring design structure that can be used to create a reusable object-oriented design. The design pattern identifies the participating classes, including their instances, responsibilities, and collaborations. Each pattern concerns one particular design problem or issue. It describes the circumstances in which the design pattern is applicable, whether the pattern can be applied in view of other design constraints, and the consequences and tradeoffs of using the pattern in a larger design. As we must eventually use our designs, the description also includes how the design pattern may be implemented using simple object-oriented concepts in object-oriented programming languages like C++ or Smalltalk.

Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design structures makes them more readily accessible to developers of new systems. The experience embodied in design patterns helps a designer evaluate which design alternatives will make a system reusable and which alternatives will compromise future extensibility. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help designers get their designs "right" the first time.

Few of the design patterns you will find in Design Patterns describe our designs. We consciously avoided describing design tricks or techniques that we have invented. Rather, we tried to only include designs that have been applied in practice to implemented and working systems. However, most of these designs have never been documented before. They are either known only as part of the object-oriented folklore, or learned only from intimate knowledge of the design of some successful object-oriented systems—neither of which are particularly useful or available references. So, although the designs described here are not new, they are presented in a new and accessible way—as a catalog of design patterns following a standard template.

  • Share ThisShare This
  • Your Account

Discussions

Make a New Comment

You must log in in order to post a comment.

Related Resources

Stephen MorrisGetting off the ground with your first iPhone app
By Stephen B. Morris on January 13, 20102 Comments

My first iPhone app – “The Day Was…” has now been through two updates. I want to talk a little about how to get started with this interesting technology. As with any software, the first step is having an idea, i.e., one or more requirements.

You Can Check Out Any Time You Like, But You Can Never Leave
By John Traenkenschuh on December 8, 2009 No Comments

Much like the line from the song, "Hotel California", Traenk finds out that membership with key Internet II sites is eternal...

Predictions and Predilections
By John Traenkenschuh on November 23, 2009 No Comments

Leaves are down; harvest is in, for the most part.  Another year comes rushing up to us.  What will it bring?

See All Related Blogs

Informit Network