[PDF] Design Patterns Elements of Reusable Object-Oriented Software

View - Download Design Patterns Elements of Reusable Object-Oriented Software

Previous PDF

Next PDF

ptg ptgC r e a t i o n al P a t t e r n s

Abstract Factory ( 8 7) P r o v i de an interface for creating families of r e l a t ed or d e p e n d e nt

o b j e c ts without specifying their c o n c r e te c l a s s e s .

Builder ( 9 7) S e p a r a te the construction of a c o m p l ex o b j e ct from its representation so

that the s a me construction p r o c e ss can create different r e p r e s e n t a t i o n s .

Factory Method ( 1 0 7) Define an interface f or creating an o b j e c t, b ut l et s u b c l a s s es d e -

c i de w h i ch c l a ss to instantiate. Factory M e t h od l e ts a c l a ss defer instantiation to s u b c l a s s e s .

Prototype ( 1 1 7) S p e c i fy t he kinds of o b j e c ts to c r e a te using a prototypical i n s t a n c e, a nd

create new o b j e c ts by c o p y i ng t h is prototype.

S i n g l e t on ( 1 2 7) Ensure a c l a ss only h as o ne i n s t a n c e, a nd provide a g l o b al point of

a c c e s s to it.

S t r u c t u r al P a t t e r n s

Adapter ( 1 3 9) Convert t he interface of a c l a ss into another interface c l i e n ts e x p e c t.

Adapter l e ts c l a s s es work t o g e t h er that c o u l d n 't o t h e r w i se b e c a u se of incompat-

i b le interfaces.

B r i d ge ( 1 5 1) D e c o u p le an abstraction from i ts implementation so that t he t wo c an vary

i n d e p e n d e n t l y .

C o m p o s i te ( 1 6 3) C o m p o se o b j e c ts into t r ee structures to r e p r e s e nt part-whole hierar-

c h i e s. C o m p o s i te l e ts c l i e n ts treat individual o b j e c ts a nd c o m p o s i t i o ns of o b j e c ts

uniformly.

Decorator ( 1 7 5) Attach additional r e s p o n s i b i l i t i es to an o b j e ct dynamically. Decorators

provide a flexible alternative to s u b c l a s s i ng for extending functionality.

F a c a de ( 1 8 5) Provide a unified interface to a set of interfaces in a s u b s y s t e m. Facade

defines a h i g h e r - l e v el interface that makes the subsystem e a s i er to u s e .

F l y w e i g ht ( 1 9 5) U se s h a r i ng to support l a r ge numbers of fine-grained o b j e c ts effi-

c i e n t l y .

P r o xy ( 2 0 7) P r o v i de a surrogate or p l a c e h o l d er for another o b j e ct to control a c c e ss to

it. ptgB e h a v i o r al P a t t e r n s Chain of Responsibility ( 2 2 3) Avoid coupling the sender of a request to its r e c e i v er by

g i v i ng more than one o b j e ct a c h a n ce to handle the r e q u e s t. C h a in the r e c e i v i ng

objects and pass the request along the chain until an object handles it. Command ( 2 3 3) Encapsulate a request as an o b j e c t, thereby letting you parameter- ize clients with different requests, queue or log requests, and support undoable operations. Interpreter ( 2 4 3) Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret s e n t e n c es in the language. Iterator ( 2 5 7) Provide a way to a c c e ss the elements of an aggregate object sequentially without e x p o s i ng its underlying representation. Mediator ( 2 7 3) Define an object that encapsulates how a set of o b j e c ts interact. Me-

diator promotes l o o se c o u p l i ng by k e e p i ng o b j e c ts from referring to e a ch o t h er

explicitly, and it lets you vary their interaction independently. Memento ( 2 8 3) Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Observer ( 2 9 3) Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. State ( 3 0 5) Allow an object to alter its behavior when its internal state changes. The o b j e ct w i ll appear to c h a n ge i ts c l a s s . Strategy ( 3 1 5) Define a family of algorithms, encapsulate each o n e, and make them

i n t e r c h a n g e a b l e. Strategy l e ts the algorithm vary independently from c l i e n ts that

use it.

Template Method ( 3 2 5) Define the s k e l e t on of an algorithm in an o p e r a t i o n, deferring

some steps to subclasses. Template Method l e ts subclasses redefine certain steps of an algorithm without changing the algorithm's structure. Visitor ( 3 3 1) Represent an operation to be performed on the elements of an object structure. Visitor l e ts you define a new operation without changing the c l a s s es of the elements on which it operates. ptgThis page intentionally left blank ptgD e s i g n Patterns ptgA d d i s o n - W e s l ey P r o f e s s i o n al C o m p u t i ng S e r i e s

Brian W. Kernighan, Consulting Editor

Matthew H. Austern, Generic Programming and the STL: Using and Extending the C++ Standard Template Library

David R. Butenhof, Programming with POSIX® Threads

B r e nt Callaghan, NFS Illustrated

Tom C a r g i l l, C++ Programming Style

W i l l i am R. C h es wick /Steven M. Bellovin/Aviel D. Rubin, Firewalls and Internet Security, Second Edition: Repelling

the Wily Hacker D a v id A. Curry, UNIX® System Security: A Guide for Users and System Administrators S t e p h en C. Dewhurst, C++ Gotchas: Avoiding Common Problems in Coding and Design

Dan Farmer/Wietse V e n e m a, Forensic Discovery

Erich Gamma/Richard Helm/Ralph Johnson/John V l i s s i d e s, Design Patterns: Elements of Reusable Object-

Oriented Software

Erich Gamma/Richard Helm/Ralph Johnson/John V l i s s i d e s, Design Patterns CD: Elements of Reusable Object-

Oriented Software

P e t er Haggar, Practical Java"" Programming Language Guide D a v id R. H a n s o n, C Interfaces and Implementations: Techniques for Creating Reusable Software

Mark Harrison/Michael McLennan, Effective Tcl/Tk Programming: Writing Better Programs with Tcl and Tk

Michi Henning/Steve V i n o s k i, Advanced CORBA® Programming with C++ Brian W. Kernighan/Rob P i k e, The Practice of Programming

S. K e s h a v, An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network

John Lakos, Large-Scale C++ Software Design

S c o tt Meyers, Effective C++ CD: 85 Specific Ways to Improve Your Programs and Designs

S c o tt M e y e r s, Effective C++, Third Edition: 55 Specific Ways to Improve Your Programs and Designs

S c o tt M e y e r s, More Effective C++: 35 New Ways to Improve Your Programs and Designs

S c o tt Meyers, Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library

Robert B. Murray, C++ Strategies and Tactics

D a v id R. Musser/Gillmer J. Derge/Atul S a i n i, STL Tutorial and Reference Guide, Second Edition:

C++ Programming with the Standard Template Library

John K. Ousterhout, Tel and the Tk Toolkit

Craig Partridge, Gigabit Networking

Radia P e r l m a n, Interconnections, Second Edition: Bridges, Routers, Switches, and Internetworking Protocols

S t e p h en A. Rago, UNIX® System V Network Programming

Eric S. Raymond, The Art of UNIX Programming

Marc J. R o c h k i n d, Advanced UNIX Programming, Second Edition

Curt S c h i m m e l, UNIX® Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers

W. Richard S t e v e n s, TCP/IP Illustrated, Volume 1: The Protocols

W. Richard S t e v e n s, TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX®

Domain Protocols

W. Richard Stevens/Bill Fenner/Andrew M. Rudoff, UNIX Network Programming Volume 1, Third Edition: The

Sockets Networking API

W. Richard Stevens/Stephen A. Rago, Advanced Programming in the UNIX® Environment, Second Edition W. R i c h a rd Stevens/Gary R. W r i g h t, TCP/IP Illustrated Volumes 1-3 Boxed Set John Viega/Gary McGraw, Building Secure Software: How to Avoid Security Problems the Right Way Gary R. Wright/W. Richard S t e v e n s, TCP/IP Illustrated, Volume 2: The Implementation Ruixi Yuan/W. Timothy Strayer, Virtual Private Networks: Technologies and Solutions

V i s i t www.awprofessional.com/series/professionalcomputing for more information about t h e s e titles.

ptgD e s i g n Patterns E l e m e n t s of Reusable Object-Oriented Software

E r i ch G a m ma

R i c h a r d H e l m

R a l p h Johnson

J o h n V l i s s i d e s

Boston • San F r a n c i s co • New York • Toronto • Montreal London • Munich • P a r is • Madrid Capetown • Sidney • Tokyo • Singapore • Mexico City

ptgM a t e r i al f r om A Pattern Language: Towns/Buildings/Construction by C h r i s t o p h er A l e x a n d e r,

c o p y r i g ht © 1 9 77 by C h r i s t o p h er A l e x a n d er is r e p r i n t ed by p e r m i s s i on of Oxford University

P r e s s, I n c .

Many of the designations used by manufacturers and s e l l e rs to distinguish their products are c l a i m ed as

trademarks. Where those designations a p p e ar in this book, and we were aware of a trademark claim, the

designations have b e en printed in initial c a p i t al letters or in all capitals.

T he author a nd p u b l i s h er have taken c a re in t he p r e p a r a t i on of this book, b ut make no e x p r e s s ed or

i m p l i ed warranty of any kind and assume no r e s p o n s i b i l i ty for errors or omissions. No l i a b i l i ty is

a s s u m ed for incidental or consequential damages in connection with or arising out of the use of the

information or programs contained herein.

T he p u b l i s h er offers d i s c o u n ts on this b o ok when o r d e r ed in quantity f or s p e c i al s a l e s. F or m o re informa-

ti on, p l e a se c o n t a c t : P e a r s on Education Corporate S a l es Division

2 01 W. 1 0 3 rd S t r e et

I n d i a n a p o l i s, IN 4 6 2 90

( 8 0 0) 4 2 8 - 5 3 31 corpsales@pearsoned.com V i s it AW on t he W e b: w w w . a w p r o f e s s i o n a l . c o m Library of Congress Cataloging-in-Publication Data

Design Patterns : e l e m e n ts of reusable o b j e c t - o r i e n t ed software / Erich Gamma ... [et al.].

p. cm. - (Addison-Wesley professional computing s e r i e s ) I n c l u d es b i b l i o g r a p h i c al r e f e r e n c es a nd i n d e x .

I S BN 0 - 2 0 1 - 6 3 3 6 1 - 2

1. O b j e c t - o r i e n t ed programming (Computer s c i e n c e) 2. Computer software - Reusability.

I. Gamma, Erich. II. S e r i e s .

Q A 7 6 . 6 4 . D 47 1 9 9 4

0 0 5 . 1 ' 2 - d c 20 9 4 - 3 4 2 64

C I P Copyright © 1 9 95 by A d d i s o n - W e s l e y

All rights reserved. No part of this publication may be reproduced, s t o r ed in a retrieval system, or

transmitted, in a ny form, or by a ny means, e l e c t r o n i c, m e c h a n i c a l, p h o t o c o p y i n g, r e c o r d i n g, or o t h e r -

wise, without t he p r i or c o n s e nt of t he p u b l i s h e r. P r i n t ed in t he U n i t ed S t a t es of A m e r i c a. P u b l i s h ed

s i m u l t a n e o u s l y in Canada. Cover art © M.C. Escher/Cordon Art - Baarn - Holland. All rights reserved.

I S B N 0-201-63361-2

T e x t printed in the United States on recycled paper at Courier Westford in Westford, Massachusetts.

3 7 t h Printing March 2009

ptgTo Karin - E.G.

To Sylvie

- R.H.

To Faith

-R.J.

To Dru Ann and Matthew

Joshua 24:15b

- J.v. ptgP r a i se for Design Patterns: Elements of Reusable

Object-Oriented Software

" T h is is one of the best written and wonderfully insightful books that I have r e ad in a g r e at l o ng while...this

b o ok e s t a b l i s h es the legitimacy of patterns in the b e st way: not by argument but by example."

- S t an L i p p m a n, C++ Report

" . . . t h is new b o ok by Gamma, Helm, Johnson, and Vlissides promises to have an important and lasting

impact on the d i s c i p l i ne of software design. B e c a u se Design Patterns bills i t s e lf as being c o n c e r n ed with

o b j e c t - o r i e n t ed software a l o n e, I fear that software developers outside the object community may i g n o re it.

This would be a shame. T h is b o ok has s o m e t h i ng for everyone who designs software. All software design-

ers use patterns; understanding better the reusable abstractions of our work can only make us better at i t . "

- Tom D e M a r c o, IEEE Software

" O v e r a l l, I think this b o ok r e p r e s e n ts an extremely valuable and unique contribution to the field because

it captures a wealth of object-oriented design experience in a compact and reusable form. T h is b o ok is

certainly one that I s h a ll turn to often in s e a r ch of powerful object-oriented design i d e a s; after a l l, that's

what r e u se is all about, isn't i t ? " - S a n j iv G o s s a i n, Journal of Object-Oriented Programming

" T h is much-anticipated b o ok lives up to its full year of advance buzz. The metaphor is of an architect's

pattern b o ok filled with t i m e - t e s t e d, usable designs. The authors have chosen 23 patterns from d e c a d es of

o b j e c t - o r i e n t ed e x p e r i e n c e. The b r i l l i a n ce of the b o ok l i es in the discipline represented by that number.

Give a c o py of Design Patterns to every g o od programmer you know who wants to be b e t t e r . " - L a r ry O ' B r i e n, Software Development

" T he s i m p le fact of the matter is that patterns have the potential to permanently a l t er the software

engineering field, catapulting it into the r e a lm of true elegant design. Of the b o o ks to d a te on this subject,

Design Patterns is far and away the best. It is a b o ok to be read, studied, internalized, and l o v e d. The b o ok

will forever change the way you view software." - S t e ve Bilow, Journal of Object-Oriented Programming

"Design Patterns is a powerful book. After a m o d e st investment of time with it, m o st C++ programmers

w i ll be a b le to s t a rt applying i ts " p a t t e r n s" to produce better software. T h is b o ok d e l i v e rs i n t e l l e c t u al

l e v e r a g e: c o n c r e te t o o ls that help us think and express ourselves more effectively. It may fundamentally

change the way you think about programming. - Tom Cargill, C++ Report ptgC o n t e n t s

P r e f a c e xi

F o r e w o r d xiii

Guide to Readers xv

1 Introduction 1

1 . 1 What Is a Design Pattern? 2

1 . 2 Design Patterns in Smalltalk MVC 4

1 . 3 Describing Design Patterns 6

1 . 4 The Catalog of Design Patterns 8

1 . 5 Organizing the Catalog 9

1 . 6 How Design Patterns Solve Design Problems 11

1 . 7 H o w t o Select a Design Pattern 28

1 . 8 H o w t o U s e a Design Pattern 29

2 A Case Study: Designing a D o c u m e n t Editor 33

2 . 1 Design Problems 33

2 . 2 Document Structure 35

2 . 3 Formatting 40

2.4 Embellishing the User Interface . 43

2 . 5 Supporting Multiple Look-and-Feel Standards 47

2 . 6 Supporting Multiple Window Systems 51

2 . 7 User Operations i 58

2 . 8 Spelling Checking and Hyphenation 64

v i i ptgv i i i CONTENTS

2 . 9 Summary 76

D e s i gn P a t t e rn C a t a l og 7 9

3 C r e a t i o n al P a t t e r ns 81

A b s t r a ct F a c t o ry 87

B u i l d er 97

F a c t o ry M e t h od 1 07

Prototype 1 17

S i n g l e t on 1 2 7

D i s c u s s i on of C r e a t i o n al Patterns 1 3 5

4 S t r u c t u r al P a t t e r ns 1 37

Adapter 1 39

B r i d ge 1 51

C o m p o s i te 1 63

D e c o r a t or 1 75

F a c a de 1 85

F l y w e i g ht 1 95

P r o xy 2 0 7

D i s c u s s i on of S t r u c t u r al Patterns 2 1 9

5 B e h a v i o r al P a t t e r ns 2 21

C h a in of R e s p o n s i b i l i ty 2 23

C o m m a nd 2 33

Interpreter 2 43

Iterator 2 57

Mediator 2 73

M e m e n to 2 83

O b s e r v er 2 93

S t a te 3 05

S t r a t e g y 315

ptgCONTENTS ix

T e m p l a t e Method 325

V i s i t o r 331

D i s c u s s i o n of Behavioral Patterns 345

6 Conclusion 351

6 . 1 What t o Expect from Design Patterns 351

6 . 2 A Brief History 355

6 . 3 The Pattern Community 356

6 . 4 An Invitation 358

6 . 5 A Parting Thought 358

A Glossary 359

B Guide to Notation 363

B . I Class Diagram 363

B . 2 Object Diagram 364

B . 3 Interaction Diagram 366

C Foundation Classes 369

C . 1 List 369

C . 2 Iterator 372

C . 3 Listlterator 372

C . 4 Point 373

C . 5 Rect 374

B i b l i o g r a p h y 375

I n d e x 383

ptgThis page intentionally left blank ptgPreface T h is book isn't an introduction to object-oriented t e c h n o l o gy or d e s i g n. Many books already do a g o od job of that. T h is book assumes you are reasonably proficient in at l e a st one object-oriented programming language, and you s h o u ld have s o me e x p e r i e n ce in object-oriented d e s i gn as w e l l. You definitely shouldn't have to rush to the nearest dictionary the moment we mention " t y p e s" and "polymorphism," or "interface" as o p p o s ed to " i m p l e m e n t a t i o n" inheritance.

On the other hand, t h is isn't an advanced t e c h n i c al treatise e i t h e r. It's a book of d e s i gn

patterns that d e s c r i b es s i m p le and e l e g a nt solutions to specific p r o b l e ms in o b j e c t -

oriented software d e s i g n. D e s i gn patterns capture s o l u t i o ns that have d e v e l o p ed and

e v o l v ed o v er time. H e n ce they aren't the d e s i g ns p e o p le tend to generate i n i t i a l l y. T h ey

reflect untold r e d e s i gn and r e c e d i ng as d e v e l o p e rs have struggled for greater r e u se

and flexibility in their software. D e s i gn patterns capture t h e se s o l u t i o ns in a s u c c i n ct

and e a s i ly a p p l i ed form. The d e s i gn patterns require neither unusual language features nor amazing program- ming tricks with which to astound your friends and managers. All can be i m p l e m e n t ed in standard object-oriented languages, though they might take a l i t t le more work than ad hoc solutions. But the extra effort invariably pays dividends in i n c r e a s ed flexibility and reusability. O n ce you understand the d e s i gn patterns and have had an " A h a !" (and not just a "Huh?") experience with them, you won't e v er think about object-oriented d e s i gn in the same way. You'll have i n s i g h ts that can make your own d e s i g ns more flexible, modular, reusable, and understandable - which is why you're interested in object- oriented technology in the first p l a c e, right? A word of warning and encouragement: Don't worry if you don't understand t h is book completely on the first reading. We didn't understand it all on the first writing! Remember that this i s n 't a book to read o n ce and put on a shelf. We hope you'll find yourself referring to it again and again for d e s i gn i n s i g h ts and for inspiration. T h is book has had a l o ng gestation. It has s e en four c o u n t r i e s, three of its authors' marriages, and the birth of two (unrelated) offspring. Many p e o p le have had a part in its development. S p e c i al thanks are due Bruce Anderson, Kent B e c k, and Andre Weinand for their inspiration and advice. We also thank those who reviewed drafts XI ptgxii PREFACE

of t he manuscript: R o g er B i e l e f e l d, Grady B o o c h, T om C a r g i l l, Marshall C l i n e, Ralph

H y r e, B r i an K e r n i g h a n, T h o m as L a l i b e r t y, Mark L o r e n z, Arthur R i e l, Doug S c h m i d t,

C l o v is T o n d o, S t e ve V i n o s k i, a nd R e b e c ca Wirfs-Brock. We a re a l so grateful to t he

team at A d d i s o n - W e s l ey for their help and p a t i e n c e: Kate H a b i b, Tiffany M o o r e, L i sa

Raffaele, Pradeepa S i v a, and John Wait. S p e c i al thanks to Carl K e s s l e r, Danny S a b b a h,

and Mark W e g m an at IBM R e s e a r ch for their unflagging support of t h is work. L a st but certainly not l e a s t, we thank everyone on the Internet and points b e y o nd who

commented on v e r s i o ns of the patterns, offered e n c o u r a g i ng w o r d s, and t o ld us that

what we were d o i ng was worthwhile. T h e se p e o p le i n c l u de but are not l i m i t ed to

J on A v o t i n s, S t e ve Berczuk, Julian B e r d y c h, Matthias B o h l e n, John Brant, Allan C l a r k e,

Paul C h i s h o l m, J e ns C o l d e w e y, D a ve C o l l i n s, J im C o p l i e n, D on D w i g g i n s, G a b r i e le E l i a,

D o ug F e l t, B r i an F o o t e, D e n is F o r t i n, Ward H a r o l d, Hermann H u e n i, N a y e em I s l a m,

Bikramjit Kalra, Paul Keefer, T h o m as Kofler, Doug L e a, Dan L a L i b e r t e, James L o n g, Ann L o u i se Luu, Pundi Madhavan, B r i an M a r i c k, Robert Martin, D a ve M c C o m b, Carl

M c C o n n e l l, C h r i s t i ne M i n g i n s, Hanspeter M o s s e n b o c k, E r ic Newton, Marianne Ozkan,

Roxsan Payette, Larry P o d m o l i k, G e o r ge R a d i n, S i ta Ramakrishnan, Russ Ramirez, A l e x a n d er Ran, Dirk R i e h l e, Bryan Rosenburg, Aamod S a n e, Duri S c h m i d t, Robert

S e i d l, X in S h u, a nd B i ll W a l k e r .

We don't c o n s i d er this c o l l e c t i on of d e s i gn patterns c o m p l e te a nd s t a t i c; it's more a

r e c o r d i ng of o ur current thoughts on d e s i g n. We w e l c o me c o m m e n ts on i t, whether

c r i t i c i s ms of o ur e x a m p l e s, r e f e r e n c es a nd known u s es we've m i s s e d, or d e s i gn pat-

terns we s h o u ld have i n c l u d e d. You can write us care of A d d i s o n - W e s l e y, or s e nd

e l e c t r o n ic mail to design-patterns@cs.uiuc. edu. You can a l so obtain softcopy

f or t he c o de in t he S a m p le C o de s e c t i o ns by s e n d i ng t he m e s s a ge " s e nd d e s i gn pattern

s o u r c e" to design-patterns-sourceics. uiuc. e d u. And now t h e r e 's a Web page at http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.html for l a t e - b r e a k i n g i n f o r m a t i o n and updates.

Mountain View, California E.G.

Montreal, Quebec R.H.

Urbana, Illinois R.J.

Hawthorne, New York J.V.

August 1994

ptgF o r e w o r d

All well-structured o b j e c t - o r i e n t ed architectures are full of patterns. I n d e e d, one of the

ways that I measure the quality of an object-oriented system is to judge whether or not its d e v e l o p e rs have paid careful attention to the common collaborations among its objects. F o c u s i ng on s u ch mechanisms during a system's development can y i e ld an

architecture that is s m a l l e r, s i m p l e r, and far more understandable than if these patterns

are ignored.

The importance of patterns in crafting c o m p l ex s y s t e ms has been l o ng r e c o g n i z ed in

o t h er d i s c i p l i n e s. In p a r t i c u l a r, C h r i s t o p h er A l e x a n d er a nd h is c o l l e a g u es w e re p e r h a ps

the first to propose the i d ea of using a pattern language to architect buildings and c i t i e s. His ideas and the contributions of others have now taken root in the o b j e c t - o r i e n t ed software community. In short, the concept of the d e s i gn pattern in software p r o v i d es a key to helping developers leverage the e x p e r t i se of other s k i l l ed architects. In this book, Erich Gamma, Richard H e l m, Ralph Johnson, and John V l i s s i d es introduce the principles of d e s i gn patterns and then offer a catalog of s u ch patterns. T h u s, this

b o ok makes t wo important c o n t r i b u t i o n s. F i r s t, it s h o ws t he r o le that patterns c an p l ay

in architecting c o m p l ex s y s t e m s. S e c o n d, it p r o v i d es a very pragmatic reference to a set

of well-engineered patterns that the practicing d e v e l o p er can apply to crafting his or her own specific applications. I'm honored to have had the opportunity to work directly with s o me of the authors of this book in architectural d e s i gn efforts. I have learned much from them, and I s u s p e ct that in reading this book, you will also.

Grady Booch

C h i e f Scientist, Rational S o f t w a r e Corporation xm ptgThis page intentionally left blank ptgGuide to Readers T h is book has two main parts. The first part (Chapters 1 and 2) d e s c r i b es what d e s i gn

patterns are and how they h e lp you d e s i gn object-oriented software. It i n c l u d es a d e s i gn

c a se study that demonstrates how d e s i gn patterns apply in practice. The s e c o nd part of the book (Chapters 3,4, and 5) is a catalog of the actual d e s i gn patterns. The catalog makes up the majority of the book. Its chapters d i v i de the d e s i gn patterns into three t y p e s: creational, structural, and behavioral. You can use the catalog hi several ways. You can read the catalog from start to finish, or you can just browse from pattern to pattern. Another approach is to study one of the chapters. That w i ll help you see how c l o s e ly related patterns distinguish t h e m s e l v e s . You can use the references between the patterns as a l o g i c al route through the catalog. T h is approach w i ll give you i n s i g ht into how patterns relate to each other, how they can be c o m b i n ed with other patterns, a nd which patterns work w e ll together. F i g u re 1 .1 (page 1 2) depicts these references g r a p h i c a l l y . Yet another way to read the catalog is to use a more p r o b l e m - d i r e c t ed approach. S k ip

to S e c t i on 1 .6 (page 2 4) to read about s o me common p r o b l e ms hi d e s i g n i ng reusable

o b j e c t - o r i e n t ed software; then read the patterns that address these problems. S o me p e o p le read the catalog through first and then use a p r o b l e m - d i r e c t ed approach to apply the patterns to their projects.

If you aren't an e x p e r i e n c ed object-oriented d e s i g n e r, then start with the s i m p l e st and

most common patterns: • Abstract Factory (page 87) • Factory Method ( 1 0 7 ) • Adapter ( 1 3 9) • O b s e r v er ( 2 9 3 ) • Composite ( 1 6 3) • Strategy ( 3 1 5 ) • Decorator ( 1 7 5) • Template Method ( 3 2 5 )

It's hard to find an o b j e c t - o r i e n t ed s y s t em that doesn't use at l e a st a c o u p le of these

patterns, and l a r ge systems use nearly all of them. T h is s u b s et w i ll h e lp you understand

design p a t t e r n s in particular and good object-oriented design in general. xv ptgThis page intentionally left blank ptgC h a p t e r 1

I n t r o d u c t i o n

D e s i g n i ng o b j e c t - o r i e n t ed software is hard, and d e s i g n i ng reusable o b j e c t - o r i e n t ed soft-

ware is e v en harder. You must find pertinent o b j e c t s, factor them into c l a s s es at the

right granularity, define c l a ss interfaces and inheritance h i e r a r c h i e s, and e s t a b l i sh key

r e l a t i o n s h i ps among them. Your d e s i gn s h o u ld be specific to the p r o b l em at hand but

a l so g e n e r al enough to a d d r e ss future p r o b l e ms and requirements. You a l so want to

a v o id r e d e s i g n, or at l e a st m i n i m i ze i t. E x p e r i e n c ed o b j e c t - o r i e n t ed d e s i g n e rs w i ll t e ll

you that a reusable and f l e x i b le d e s i gn is difficult if not i m p o s s i b le to get " r i g h t" the first

time. Before a d e s i gn is finished, they usually try to reuse it s e v e r al t i m e s, modifying it

e a ch t i m e .

Y et e x p e r i e n c ed o b j e c t - o r i e n t ed d e s i g n e rs do make g o od d e s i g n s. Meanwhile n ew

d e s i g n e rs are o v e r w h e l m ed by the options a v a i l a b le and tend to fall back on n o n -

o b j e c t - o r i e n t ed t e c h n i q u es they've used before. It takes a l o ng time for n o v i c es to learn

what g o od o b j e c t - o r i e n t ed d e s i gn is a ll about. E x p e r i e n c ed d e s i g n e rs evidently know

s o m e t h i ng i n e x p e r i e n c ed o n es don't. What is it?

One thing e x p e rt d e s i g n e rs know not to do is s o l ve every problem from first p r i n c i p l e s.

Rather, they r e u se s o l u t i o ns that have worked for them in the past. When they find a

g o od s o l u t i o n, they use it again and again. S u ch e x p e r i e n ce is part of what makes them

e x p e r t s. Consequently, you'll find recurring patterns of c l a s s es and communicating

o b j e c ts in many o b j e c t - o r i e n t ed s y s t e m s. T h e se patterns s o l ve s p e c i f ic d e s i gn p r o b l e ms

and make o b j e c t - o r i e n t ed d e s i g ns more flexible, elegant, and ultimately r e u s a b l e. T h ey

h e lp d e s i g n e rs r e u se successful d e s i g ns by basing n ew d e s i g ns on prior e x p e r i e n c e.

A d e s i g n er who is familiar with s u ch patterns can apply them immediately to d e s i gn p r o b l e ms without having to r e d i s c o v er them. An analogy w i ll help illustrate the point. N o v e l i s ts and playwrights rarely d e s i gn

t h e ir plots from scratch. Instead, they follow patterns l i ke " T r a g i c a l ly F l a w ed H e r o"

(Macbeth, Hamlet, e t c .) or " T he Romantic N o v e l" ( c o u n t l e ss romance n o v e l s ). In the

s a m e w a y , o b j e c t - o r i e n t e d d e s i g n e r s follow patterns like "represent states with objects"

1 ptg2 INTRODUCTION CHAPTER 1 and "decorate o b j e c ts so you can e a s i ly add/remove features." O n ce you know the pattern, a lot of d e s i gn d e c i s i o ns follow automatically. We all know the value of d e s i gn experience. How many t i m es have you had d e s i gn deja- vu

- that f e e l i ng that you've s o l v ed a p r o b l em before b ut n ot k n o w i ng e x a c t ly w h e re or

how? If you c o u ld remember the details of the previous p r o b l em and how you s o l v ed

i t, then you c o u ld reuse the e x p e r i e n ce instead of r e d i s c o v e r i ng it. H o w e v e r, we don't

do a g o od job of recording e x p e r i e n ce in software d e s i gn for others to u s e .

T he purpose of this book is to r e c o rd e x p e r i e n ce in d e s i g n i ng o b j e c t - o r i e n t ed software as

d e s i gn patterns. E a ch d e s i gn pattern s y s t e m a t i c a l ly n a m e s, e x p l a i n s, a nd e v a l u a t es an

important and recurring d e s i gn in object-oriented s y s t e m s. Our g o al is to capture d e s i gn

e x p e r i e n ce in a form that people can use effectively. To t h is end we have documented some of the most important d e s i gn patterns and present them as a c a t a l o g .

D e s i gn patterns make it e a s i er to reuse successful d e s i g ns and a r c h i t e c t u r e s. E x p r e s s i ng

p r o v en t e c h n i q u es as d e s i gn patterns m a k es t h em m o re a c c e s s i b le to d e v e l o p e rs of

new systems. D e s i gn patterns help you c h o o se d e s i gn alternatives that make a system

reusable and avoid alternatives that compromise r e u s a b i l i t y. D e s i gn patterns can e v en

improve the documentation and maintenance of e x i s t i ng systems by furnishing an e x p l i c it specification of c l a ss and object interactions and their underlying intent. Put s i m p l y, d e s i gn patterns help a d e s i g n er get a d e s i gn " r i g h t" faster. None of the d e s i gn patterns in this book d e s c r i b es new or unproven d e s i g n s. We have included only d e s i g ns that have been applied more than o n ce in different s y s t e m s. Most

of t h e se d e s i g ns have never been documented before. T h ey are e i t h er part of the folklore

of the object-oriented community or are elements of s o me successful object-oriented systems - neither of which is e a sy for novice d e s i g n e rs to learn from. So although t h e se

d e s i g ns aren't n e w, we capture them in a new and a c c e s s i b le way: as a catalog of d e s i gn

patterns having a consistent format.

D e s p i te t he b o o k 's s i z e, t he d e s i gn patterns in it capture o n ly a fraction of what an e x p e rt

might k n o w. It doesn't have any patterns dealing with c o n c u r r e n cy or distributed pro- gramming or real-time programming. It doesn't have any application d o m a i n - s p e c i f ic patterns. It doesn't t e ll you how to build user interfaces, how to write d e v i ce d r i v e r s, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too.

1 . 1 What Is a D e s i g n P a t t e r n ?

C h r i s t o p h er A l e x a n d er s a y s, " E a ch pattern d e s c r i b es a p r o b l em w h i ch o c c u rs o v er a nd

over again in our environment, and then d e s c r i b es the c o re of the s o l u t i on to that

p r o b l e m, in such a way that you can use this solution a m i l l i on times o v e r, without e v er

d o i ng it t he s a me w ay t w i c e" [ A I S + 7 7, p a ge x }. E v en though A l e x a n d er w as t a l k i ng

about patterns in buildings and towns, what he says is true about o b j e c t - o r i e n t ed d e s i gn

patterns. Our solutions are expressed in terms of objects a n d interfaces instead of walls ptgSECTION 1.1 WHAT IS A DESIGN PATTERN? 3 and d o o r s, but at the c o re of both kinds of patterns is a solution to a problem in a context. In g e n e r a l, a pattern has four essential elements:

1. The p a t t e rn n a me is a handle we can use to describe a design problem, its so-

lutions, and c o n s e q u e n c es in a word or two. Naming a pattern immediately i n c r e a s es our d e s i gn vocabulary. It lets us design at a higher l e v el of abstraction. Having a vocabulary for patterns lets us talk about them with our c o l l e a g u e s, in our documentation, and even to ourselves. It makes it easier to think about d e s i g ns and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.

2. The p r o b l em d e s c r i b es when to apply the pattern. It explains the problem and its

context. It might d e s c r i be specific design problems such as how to represent algo- rithms as o b j e c t s. It might d e s c r i be c l a ss or object structures that are symptomatic of an inflexible d e s i g n. S o m e t i m es the problem will include a list of conditions that must be met before it makes s e n se to apply the pattern.

3. The solution d e s c r i b es the elements that make up the design, their relationships,

r e s p o n s i b i l i t i e s, and collaborations. The solution doesn't describe a particular concrete d e s i gn or implementation, because a pattern is l i ke a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a d e s i gn problem and how a general arrangement of elements ( c l a s s es and objects in our case) s o l v es it.quotesdbs_dbs14.pdfusesText_20

[PDF] design patterns in c++ tutorial pdf

[PDF] design patterns in java pdf

[PDF] design patterns in java with real life examples

[PDF] design patterns in ooad pdf

[PDF] design patterns in swift 5

[PDF] design patterns in swift medium

[PDF] design patterns interview questions

[PDF] design patterns ios

[PDF] design patterns java

[PDF] design patterns lecture notes

[PDF] design patterns midterm exam

[PDF] design patterns pdf github

[PDF] design patterns quiz questions

[PDF] design patterns tutorial for beginners

[PDF] design patterns tutorials point pdf