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

Where to Find Agile Development Techniques Process Content?
By Joshua Barnes on April 15, 2010 No Comments

In some recent blog posts I have discussed developing a process for small app development outside of the IT area as well as applying software development techniques to financial modeling.  I have also covered a little about the process used, providing some additional context on the mini- assessment as well as the delivery mechanism (process authoring and management tool).  Today I wanted to share some thoughts about “method content”, the actual pieces of the process that are the methodology.

Using a Process Management Tool
By Joshua Barnes on April 14, 2010 No Comments

Over the years I have evaluated and demoed various tools to create, modify, or publish processes, the two process management tool platforms we use most often are Rational Method Composer, “RMC”, and the Eclipse Process Framework Composer, “EPF Composer”.

Software Development Practices Applied to Financial Modeling
By Joshua Barnes on April 6, 2010 No Comments

The current state of the economy and its financial crisis has required organizations to put additional structure and scrutiny to financial model risk management.

See All Related Blogs

Informit Network