benefit familiarity understanding initiation consternation ignorance

Transcription

1 Designing with Patterns John Vlissides T.J. Watson Research IBM 1996{1999 by John Vlissides. All rights reserved. c from Design Patterns: Elements of Reusable Object-Oriented Software c 1995 by Diagrams Publishing Company. All rights reserved. Diagrams may not be reproduced, stored Addison-Wesley a retrieval system, or transmitted in any form or by any means, electronic, mechanical, in photocopying, recording, or otherwise, without the prior written permission of the publisher. 1 Introduction Stages of Design Pattern awareness: benefit familiarity understanding consternation ignorance initiation 2

2 Objectives Learn to apply design patterns to the design process nd the right patterns understand (un)applicability see when and how to bend a pattern evaluate design trade-os eectively Learn by (counter)example 3 Designing a File System Running example Design problems: 1. Structure 2. Symbolic links 3. Open-ended functionality 4. Single-user protection 5. Multi-user protection 6. Notication 4

3 structures! Composite pattern Tree of thumb Rule File System Structure Problem: represent le system elements (les, directories) for end-user: le system of arbitrary size and complexity for programmer: easy to deal with and extend / bin/ user/ tmp/ ls tom/ dick/ harry/ junk 5 File System Structure (cont'd) Choice hinges on importance of uniformity and extensibility Application issues: choosing participants: Component, Leaf, and Composite choosing operations to treat uniformly 6

4 Applicability must be composed recursively, objects there should be no distinction between individual and composed elements, and objects in the structure can be treated uniformly and Consequences uniformity: treat components the same regardless of complexity + Implementation do Components know their parents? uniform interface for both leaves and composites? don't allocate storage for children in Component base class Glyphs, Styles InterViews Components, MacroCommands Unidraw File System Structure (cont'd) Composite object structural Intent individual objects and multiple, recursively-composed objects uniformly treat Structure Component operation() add(component) remove(component) getchild(int) Leaf operation() Composite operation() add(component) remove(component) getchild(int) children forall g in children g.operation(); 7 File System Structure (cont'd) Composite (cont'd) object structural + extensibility: new Component subclasses work wherever old ones do, overhead: might need prohibitive numbers of objects responsibility for deleting children Uses Known VObjects ET++ 8

5 Leaf, for objects that have no children File, the le object! Composite, for objects that have children Directory, the directory object!! Node File System Structure (cont'd) Mapping Composite participants to le system classes: Component, the uniform interface Node File Directory children 9 File System Structure (cont'd) What can File objects do? return their name and protection stream their contents in and out What can Directory objects do? return their name and protection enumerate their children adopt and orphan children 10

6 get name/protection common Obviously stream in/out common Less-obviously enumerate children for recursion, hiding internal data structure Needed adopt & orphan between type safety and uniformity Trade-o Example: mkdir \mkdir newsubdir" new newsubdir subdirectory! \mkdir subdira/subdirb/newsubdir" new newsubdir subdirectory of subdirb! File System Structure (cont'd) What uniform interface does Node dene? Could apply Iterator instead 11 File System Structure (cont'd) adopt/orphan interface simplies clients Uniform long as Leaf objects can handle them gracefully As 12

7 void mkdir (Directory current, String path) { subpath = subpath(path); String (subpath == null) { if (find(path, current) == null) { if Directory(path)); current.adopt(new else { else { name = head(path); String Must return a Node (child!= null) { if subpath); mkdir(child, else { + " nonexistent."); System.err.println(name Node find (String name, Directory current) { child = null; Node (int i = 0; child = current.getchild(i); ++i) { for (name.equals(child.getname())) { if null; return File System Structure (cont'd) Naive mkdir implementation System.err.println(path + " exists."); Node child = find(name, current); 13 File System Structure (cont'd) find searches for a child with the given name return child; 14

8 mkdir takes a Directory, not a Node... // node = find(name, current); Node (node!= null) { if (node instanceof Directory) { if node, subpath); mkdir((directory) else { else {... // abstract class Node { void adopt (Node child) { void orphan (Node child) { + " not found."); System.err.println(child.getName()... // File System Structure (cont'd) But mkdir won't compile! Using instanceof adds a control path System.err.println(getName() + " is not a directory."); 15 File System Structure (cont'd) Solution: Treat adopt and orphan uniformly declare them in Node interface dene default behavior System.err.println(getName() + " is not a directory."); Only change to mkdir is its signature: void mkdir (Node current, String path) {... 16

9 File System Structure (cont'd) Result: Node getname() getprotection() streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) File streamin(istream) streamout(ostream) Directory streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) children 17 Symbolic Links Problem: add symbolic link capability uninvasively should work across directories, le systems, even machines / user/ tom/ dick/ harry/ richard/ 18

10 consider how design patterns solve design problems study section 1.6 no time today IOW, scan intent sections brute-force study how patterns interrelate (\spaghetti diagram," etc.) too involved, but getting warmer still look at patterns of relevant purpose (creational, structural, behavioral) examine a cause of redesign (listed on p. 24) worried about that just yet not Symbolic Links (cont'd) Finding the right pattern Symbolic Links (cont'd) Finding the right pattern... symbolic links suggest structural purpose consider what should be variable in your design (Table 1.2) 20

11 Symbolic Links (cont'd) Variabilities imparted by structural patterns Adapter: interface to an object Bridge: implementation of an object Composite: object structure and composition Decorator: responsibilities without subclassing Facade: interface to a subsystem Flyweight: storage costs of objects Proxy: how an object is accessed and/or its location 21 Symbolic Links (cont'd) Proxy structure Subject request()... RealSubject request()... realsubject Proxy request() realsubject >request();... Proxy is a stand-in for RealSubject Proxy must match Subject interface 22

12 ! Node Proxy, the stand-in class Link, the symbolic link object! Node is the RealSubject! this couldn't work without Composite's uniform interface! N.B.: Symbolic Links (cont'd) Mapping Proxy participants to le system classes: Subject, the interface to match RealSubject, to which the proxy refers!??? Problem: want to commit RealSubject to either File or Directory Don't 23 Symbolic Links (cont'd) Solution: look at Proxy's description of the Proxy participant: maintains a reference that lets the proxy access the [Proxy] subject. Proxy may refer to a Subject if the RealSubject real and Subject interfaces are the same. 24

13 class Link extends Node { Node getchild (int n) {... // Symbolic Links (cont'd) Link implementation: delegate all operations to RealSubject Example: return _subject.getchild(n); Additional Link-specic operation: Node getnode () { return _subject; (for clients who know they are dealing with a Link) 25 from Proxy pattern from Composite pattern Interlude Node getname() getprotection() streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) subject Link streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) getnode() File streamin(istream) streamout(ostream) Directory streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) children 26

14 operations! Visitor pattern Externalizing hinges on stability of Element class hierarchy Choice Open-Ended Functionality Problem: clients want to do arbitrarily many operations on le system objects cat, ls, du, chmod, chown,... must avoid treating Node interface as a dumping ground 27 Open-Ended Functionality (cont'd) Consequences: + recovers type information without downcasts + consolidates and encapsulates functionality in Visitor object, new ConcreteElements may require changing Visitor interface, circular dependency between Visitor and Element interfaces 28

15 Applicability when classes dene many unrelated operations class relationships of objects in the structure rarely change, but the on them change often operations Consequences exibility: visitor and object structure are independent + circular dependency between Visitor and Element interfaces, Visitor brittle to new ConcreteElement classes, Implementation double dispatch Open-Ended Functionality (cont'd) Visitor object behavioral Intent operations on an object structure so that they can vary centralize independently but still behave polymorphically algorithms over the structure maintain state that's updated during traversal Client ObjectStructure Element accept(visitor) Structure Visitor visitconcreteelement1(concreteelement1) visitconcreteelement2(concreteelement2) ConcreteElement1 ConcreteElement2 accept(visitor v) accept(visitor v) ConcreteVisitor visitconcreteelement1(concreteelement1) visitconcreteelement2(concreteelement2) v.visitconcreteelement1(this) v.visitconcreteelement2(this) 29 Open-Ended Functionality (cont'd) object behavioral Visitor (cont'd) + localized functionality general interface to elements of object structure Uses Known insmalltalk-80 compiler ProgramNodeEnumerator IRIS Inventor scene rendering 30

16 3. Dene CatVisitor subclass of NodeVisitor abstract class NodeVisitor { void visit(node n) { // default void visit(file f) { visit((node) f); void visit(directory d) { visit((node) d); void Node.accept (NodeVisitor v) { v.visit(this); => NodeVisitor.visit(Node) // void File.accept (NodeVisitor v) { v.visit(this); => NodeVisitor.visit(File) // void Directory.accept (NodeVisitor v) { v.visit(this); => NodeVisitor.visit(Directory // void Link.accept (NodeVisitor v) { v.visit(this); => NodeVisitor.visit(Link) // Open-Ended Functionality (cont'd) Dening a CatVisitor (lists a le) 1. Dene NodeVisitor base class 2. Add accept operation to Node base class and subclasses 31 Open-Ended Functionality (cont'd) void visit(link l) { visit((node) l); accept operations: 32

17 class CatVisitor extends NodeVisitor { void visit (File f) { void visit (Directory d) { cat a directory."); System.err.println("Can't void visit (Link l) { l.getnode().accept(this); cat = new CatVisitor(); CatVisitor node.accept(cat); class HardLink extends Node { void accept (NodeVisitor v) { v.visit(this); => NodeVisitor.visit(Node) //... // acts as catch-all visit(node) problem if no visitor treats HardLink objects specially and/or No behavior adequate default need RTTI... Otherwise, Open-Ended Functionality (cont'd) CatVisitor subclass implementation f.streamout(system.out); Usage: 33 Open-Ended Functionality (cont'd) What if Element hierarchy isn't stable? Example: HardLink is a new subclass of Node: 34

18 void accept (NodeVisitor nv) { (nv instanceof CatVisitor) { if cv = (CatVisitor) nv; CatVisitor cv.visit(this); else { this); nv.visit((node) NodeVisitor subclasses unchanged if you update NodeVisitor interface + new NodeVisitor subclasses force change in Node subclasses, void visit (Node n) { (n instanceof HardLink) { if else { super.visit(n); RTTI in potentially every NodeVisitor subclass, # branches proportional to # new Node subclasses? Open-Ended Functionality (cont'd) Example: CatVisitor must deal with HardLinks specially 1. Use RTTI in the element: // => CatVisitor-specific visit(hardlink) // do the default? # branches proportional to # new NodeVisitor subclasses 35 Open-Ended Functionality (cont'd) 2. Use RTTI in the visitor: // do something special for hard links // do the default Node subclasses unchanged if you update NodeVisitor interface + overloading) (assumes 36

19 protect le system objects from inadvertent corruption defense against malicious corruption No make nodes (un)readable and/or (un)writable should work for other protection modes, too Approach an unreadable node can't divulge its contents les shouldn't respond to streamout requests! an unwritable node can't be modied shouldn't respond to streamin! Single-User Protection Problem: 37 Single-User Protection (cont'd) How do these protection modes aect a node's behavior?! directories shouldn't enumerate their children! (C++) must disable destructor What patterns support these (anti)responsibilities? 38

20 many strategy objects does a node use? How per node, one per Node operation,...? One multiple, how do they work together? If do Node subclasses delegate to ProtectionStrategies? What Single-User Protection (cont'd) Observation 1: Protection behavior must vary dynamically user can change protection at any time suggests a behavioral pattern, especially Strategy or State Decorator is a non-invasive alternative to Strategy Observation 2: Access control suggests Proxy 39 Single-User Protection (cont'd) Client Node ProtectionStrategy Applying Strategy getname() getprotection() streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node)????????? State poses similar questions 40

21 Single-User Protection (cont'd) Is Decorator any better? Node getname() getprotection() streamin(istream) streamout(ostream) getchild(int) adopt(node) orphan(node) getprotection() streamout(ostream) areadprotectiondeco streamin(istream) awriteprotectiondeco ProtectionDecorator afile ReadProtectionDeco WriteProtectionDeco 41 Single-User Protection (cont'd) Decorator's drawbacks: When a node's protection changes, what happens to existing to it? references Object identity problem Lots more objects! high overhead Proxy has similar drawbacks 42

22 adding objects isn't helping adds complexity Delegation Single-User Protection (cont'd) New observations: Objects add overhead Strategy, State, Decorator, and Proxy are all object patterns How about using class pattern(s) to vary behavior? 43 Single-User Protection (cont'd) Template Method can vary behavior of each operation independently in subclasses no object or delegation overhead To apply it, determine variant and invariant parts invariant: determine current protection (read and/or write) variant: response (normal operation or nop/error message) 44

23 Applicability to implement invariant aspects of an algorithm once and let subclasses variant parts dene to localize common behavior in a class to increase code reuse Consequences leads to inversion of control (\Hollywood principle": don't call us we'll + you) call promotes code reuse + Implementation virtual vs. non-virtual template method few vs. lots of primitive operations naming conventions (do- prex) Single-User Protection (cont'd) class behavioral Template Method Intent the skeleton of an algorithm in an operation, deferring some steps to dene subclasses to control subclass extensions AbstractClass templatemethod() primitiveoperation1() primitiveoperation2()... primitiveoperation1()... primitiveoperation2()... Structure ConcreteClass primitiveoperation1() primitiveoperation2() 45 Single-User Protection (cont'd) class behavioral Template Method (cont'd) + lets you enforce overriding rules, must subclass to specialize behavior Uses Known about all object-oriented systems (especially frameworks) just 46

24 abstract class Node { final void streamout (OutputStream out) {... // (isreadable()) { if dostreamout(out); else { dowarning(unreadablewarning); Pass doomed node to primitive operations 3. doesn't have this Static Node::Delete (Node* node) { void (node->iswritable()) { if node; delete else { Single-User Protection (cont'd) Typical implementation: isreadable, dostreamout, and dowarning are primitive operations 47 Single-User Protection (cont'd) Preventing deletion of unwritable node in C++: 1. Protect destructor 2. Dene static void Node::Delete(Node*) as template method node->dowarning(undeletablewarning); 48

25 the Unix le system model Mimic \group," \other" protection modes \user," Multi-User Protection Problem: extend protection scheme to support multiple users associate users with les support named groups of users 49 Multi-User Protection (cont'd) Questions: how to model a user? how to authenticate a user? how does authentication impact node operations? 50

26 wemodel a user as an object Assume metaphor Natural Multi-User Protection (cont'd) Stick with it until it proves unworkable One User instance per \login name" (in Unix sense) What can we do with a User object? 51 Multi-User Protection (cont'd) More important: What can't we do with a User? identies a user to the system must prevent masquerade! must control instantiation process login name + valid password ) User instance 52

27 Abstract Factory: no \families"; not averse to instantiating a class concrete Applicability when there must be exactly one instance of a class, and it must be from a well-known access point accessible when the sole instance should be extensible by subclassing, and clients Multi-User Protection (cont'd) Encapsulating the instantiation process A relevant creational pattern? Builder: we're not varying the creation process Factory Method: see Abstract Factory Prototype: can't leave prototypes lying around Singleton: need > 1 User object Multi-User Protection (cont'd) Singleton object creational Intent a class only ever has one instance, and provide a global point of access ensure to it. should be able to use an extended instance without modifying their code Structure Singleton static instance() singletonoperation() getsingletondata() return uniqueinstance static uniqueinstance singletondata 54

28 Consequences reduces namespace pollution + makes it easy to change your mind and allow more than one instance + allow extension by subclassing + Implementation static instance operation ChangeSet, the set of changes to code Smalltalk-80 Session object InterViews permits a variable number of instances. The [Singleton] makes it easy to change your mind and allow more pattern Multi-User Protection (cont'd) Singleton (cont'd) object creational same drawbacks of a global if misused, implementation may be less ecient than a global,, concurrency pitfalls registering the singleton instance Uses Known Unidraw object Unidraw's 55 Multi-User Protection (cont'd) From Singleton's Consequences: one instance of the Singleton class. Moreover, you can than the same approach to control the number of instances use the application uses. Only the [Instance] operation that that access to the Singleton instance needs to change. grants We want one and only one User instance per user 56

29 static final User login (String loginname, String password) { (password incorrect for loginname) { if (a User instance exists for loginname) { if it; return else { new User instance for loginname; return Multi-User Protection (cont'd) User modies Singleton's Instance operation a bit: return null; 57 Multi-User Protection (cont'd) Recap of login's properties globally accessible no more than one User object per login name can return null (or 0) if it fails cannot be changed by subclassing 58

30 Using a User operations only work for certain user(s) Node by who \owns" the node and its protection mode Dened Pass User in each call 1. e.g., void streamout(outputstream, User); Dene an \implicit" User 2. signatures unchanged from single-user versions Multi-User Protection (cont'd) How do Node operations ascertain the user? 59 Multi-User Protection (cont'd) Two approaches: \stateless" design can be a nuisance \stateful" design requires global set/getuser interface 60

31 char* getname(const User* = 0); const Protection& getprotection(const User* = 0); const setname(const char*, const User* = 0); void setprotection(const Protection&, const User* = 0); void streamin(istream&, const User* = 0); void streamout(ostream&, const User* = 0); void getchild(int, const User* = 0); Node* adopt(node*, const User* = 0); void void streamout (OutputStream out, User user) { (isreadableby(user)) { if dostreamout(out); else { boolean isreadableby (User user) { isowner = user.owns(this); boolean return && isuserreadable() isowner Multi-User Protection (cont'd) In C++, default parameters allow both approaches: void orphan(node*, const User* = 0); In Java, use overloading (! double the operations) 61 Multi-User Protection (cont'd) Typical impact on template methods: dowarning(unreadablewarning); // true iff user's login name matches node's owner!isowner && isotherreadable(); 62

32 Multi-User Protection (cont'd) More questions: how to model groups of users? how to associate users and groups? 63 Multi-User Protection (cont'd) "family" group matt Example grouping: dru helen root adm vlis daemon cope richard "sys" group erich johnson "patterns" group 64

33 User-group not a recursive relationship 1. in Unix, at least Not Not strictly hierarchical 2. user can belong to more than one group A Questionable to treat users and groups uniformly 3. a group? Pass it around as authentication? Login Multi-User Protection (cont'd) Groups as objects from existing hierarchy, or new class (hierarchy)? Subclass User subclass Assume A Composite of users? User Group children 65 Multi-User Protection (cont'd) Why Composite is not applicable: 66

34 # users # groups nd all group members without scanning all users! Multi-User Protection (cont'd) Still need to associate groups and users Need a two-way mapping for eciency checks for group membership should be fast, too 67 Multi-User Protection (cont'd) User Group One solution: Drawbacks: references hard to change noninvasively all objects saddled with cost of a (pointer to a) collection tangle of references between User and Group objects 68

35 Applicability there's cooperative behavior that can't be assigned to an individual object a set of objects communicate in well-dened but complex ways ordering of operations may change as system evolves Multi-User Protection (cont'd) Managing object interconnections! Mediator Before: After: Grouping users groups users groups Grouping is probably a singleton 69 Multi-User Protection (cont'd) Mediator object behavioral Intent an object that encapsulates how a set of objects interact to promote dene loose coupling and to let you vary their interaction independently Mediator mediator Colleague Structure ConcreteMediator ConcreteColleague1 ConcreteColleague2 70

36 Consequences encapsulates communication + simplies protocols between objects + avoids pushing mediation responsibility into one or more colleagues + Implementation using static members instead of a separate class abstract class Grouping { static Grouping getgrouping(); static void setgrouping(grouping); static void setgrouping(grouping, User); void register(user, Group); void register(user, Group, User); void unregister(user, Group); void unregister(user, Group, User); Group getgroup(string loginname, int index); String getuser(group, int index); Multi-User Protection (cont'd) Mediator (cont'd) object behavioral, Mediator can become complex and monolithic Singleton mediators Uses Known Editor, CSolver Unidraw's ET++ PrinterManager, DialogDirector 71 Multi-User Protection (cont'd) Grouping interface // returns singleton 72

37 \notication," \dependency" portend Observer pattern \Update," particularly rich one A Notication Problem: Clients sensitive to le system changes Example: Files created by one application appear in another: save a few Web pages... Don't want to hit \Refresh" to see the new les! Other examples: mail arrival, clipboards, embedded documents 73 Notication (cont'd) Application issues: choosing participants: (Concrete)Subject, (Concrete)Observer the Subject-Observer mapping: how fancy? 74

38 Applicability when an abstraction has two aspects, one dependent on the other when a change to one object requires changing others, and you don't know many objects need to be changed how when an object should notify other objects without making assumptions who these objects are about Consequences modularity: subject and observers mayvary independently + extensibility: can dene and add any number of observers + customizability: dierent observers provide dierent views of subject + Implementation subject-observer mapping (Subjects and Views) InterViews (Data Objects and Views) Andrew Notication (cont'd) Observer object behavioral Intent a one-to-many dependency between objects so that when one object dene changes state, all its dependents are notied and updated automatically Subject observers Observer Structure attach(observer) detach(observer) notify() for all o in observers { o.update() update() ConcreteObserver ConcreteSubject getstate() subjectstate return subjectstate subject update() observerstate = subject.getstate() observerstate 75 Notication (cont'd) object behavioral Observer (cont'd) unexpected updates: observers don't know about each other, update overhead: might need hints, dangling references avoiding observer-specic update protocols: the push and pull models registering modications of interest explicitly Uses Known Model-View-Controller (MVC) Smalltalk 76

39 any object might observe (= Observer) and! object might be observed (= Subject) any Subject and Observer as interfaces Dene you give subject and/or observer characteristics to any class Lets Subject { interface attach(observer); void detach(observer); void notify(); void abstract class Node implements Subject {... // class Browser implements Observer {... // Observer { interface update(subject); void Notication (cont'd) Mapping Observer participants to le system classes web browser Observer file browser Observer Directory noties le browser of change in contents: directory Subject directory file new file 77 Notication (cont'd) 78

40 class Browser implements Observer {... // void update (Subject s) { (_opendirectories.contains(s)) { if d = (Directory) s; Directory update display(s) of d // abstract class Node implements Subject {... // void attach (Observer o) { _observers.addelement(o); void detach (Observer o) { _observers.removeelement(o); void notify () { (int i = 0; i < _observers.size(); ++i) { for o = (Observer) _observers.elementat(i); Observer o.update(this); Notication (cont'd) Subject parameter to update Note may observe multiple subjects Observer private Vector _opendirectories; 79 Notication (cont'd) private Vector _observers; All concrete subjects implement something similar to this... 80

41 Subject operations in a change manager Consolidating eliminate them from Subject entirely Can class ChangeManager { void register (Subject s, Observer o) { (observers == null) { if = new Vector(); observers observers.addelement(o); void unregister (Subject s, Observer o) { observers = (Vector) _registry.get(s); Vector (observers!= null) { if observers.removeelement(o); class ChangeManager {... // void notify (Subject s) { e = _registry.elements(); Enumeration (e.hasmoreelements()) { while observers = (Vector) e.nextelement(); Vector (int i = 0; i < observers.size(); ++i) { for o = (Observer) observers.elementat(i); Observer Notication (cont'd) Reuse by composition, not inheritance Vector observers = (Vector) _registry.get(s); _registry.put(s, observers); // Notication (cont'd) o.update(s); private Hashtable _registry = new Hashtable(); yet another Mediator may beasingleton 82

42 protection: Template Method Single-user Strategy, Decorator, orproxy Not Singleton: creating users, \implicit" user, Grouping { Not Composite Summary Structure: Composite Symbolic links: Proxy Open-ended functionality: Visitor Multi-user protection: Mediator: groups Notication: Observer 83 Summary (cont'd) Mediator:Colleague Observer:Subject Subject ChangeManager Observer Mediator:Colleague Observer Observer:ChangeManager Mediator:ConcreteMediator Composite:Component Proxy:Subject TemplateMethod:AbstractClass Visitor:Element Node NodeVisitor Visitor Link File Directory CatVisitor Visitor:ConcreteVisitor Composite:Leaf Observer:ConcreteSubject Proxy TemplateMethod:ConcreteClass Composite:Leaf Observer:ConcreteSubject Proxy:RealSubject TemplateMethod:ConcreteClass Composite Observer:ConcreteSubject Proxy:RealSubject TemplateMethod:ConcreteClass User Grouping Group Mediator:ConcreteColleague Singleton (variant) Mediator:ConcreteMediator Singleton Mediator:ConcreteColleague 84

43 patterns can't guarantee a good overall architecture Design just micro-architectures They're the solutions of some patterns look similar: add a level of indirection." \Just the patterns takes time Learning have to experience the problem to appreciate the solution You Experiences Creativity still required you might never implement a pattern the same way twice not all design decisions are covered by patterns 85 Experiences (cont'd) Not always obvious which design pattern to apply! State, Strategy, Bridge,... but the problem/intent they address is dierent 86

44 therefore design to be as exible as needed, not as exible as possible systems that work evolved from simple systems that \Complex worked." Booch dense application Overly a class that participates in all 23 patterns! E.g., Pattern Pitfalls Overenthusiasm patterns have costs (indirection, complexity) \Start stupid and evolve." Beck Reducing the world to design patterns 87 (Design) Pattern References Timeless Way of Building, Alexander; Oxford, 1979; The ISBN A Pattern Language, Alexander; Oxford, 1977; ISBN Patterns, Gamma, et al.; Addison-Wesley, 1995; Design ; CD version ISBN ISBN Software Architecture, Buschmann, et al.; Wiley, Pattern-Oriented ISBN ; Analysis Patterns, Fowler; Addison-Wesley, 1996; ISBN Best Practice Patterns, Beck; Prentice Hall, 1997; Smalltalk X ISBN Design Patterns Smalltalk Companion, Alpert, et al.; The 1998; ISBN Addison-Wesley, AntiPatterns, Brown, et al.; Wiley, 1998; ISBN

45 More Books: Languages of Program Design (Addison-Wesley) Pattern 1, Coplien, et al., eds.; 1995; ISBN Vol. 2, Vlissides, et al., eds.; 1996; ISBN Vol. 3, Martin, et al., eds.; 1998; ISBN Vol. Vol. 4, Harrison, et al., eds.; 2000; ISBN Programming in Java, Lea; Addison-Wesley, 1997; Concurrent ISBN UML and Patterns, Larman; Prentice Hall, 1997; Applying ISBN Hatching: Design Patterns Applied, Vlissides; Pattern 1998; ISBN Addison-Wesley, Future Books: Pattern Almanac, Rising; Addison-Wesley, 2000; The ISBN 89 Early Papers: \Object-Oriented Patterns," P. Coad; Comm. of the ACM, 9/92 Frameworks using Patterns," R. Johnson; \Documenting '92 OOPSLA Patterns: Abstraction and Reuse of Object-Oriented \Design Gamma, Helm, Johnson, Vlissides, ECOOP '93. Design," Columns: C++ Report, Dr. Dobbs Sourcebook, JOOP, ROAD 90

46 discussion on Pattern-Oriented Architecture Software discussion on patterns for business processes discussion on patterns for distributed systems Conferences: 2000: Pattern Languages of Programs PLoP 2000, Monticello, Illinois, USA September 2000 EuroPLoP 2000, Kloster Irsee, Germany July 2000 ChiliPLoP 2000, Wickenburg, Arizona, USA March 2000 KoalaPLoP 2000, Melbourne, Australia May See for up-to-the-minute information. 91 Mailing Lists: present and rene patterns general discussion on patterns discussion on Design Patterns discussion on user interface design patterns See for an up-to-date list. 92

47 Lists Mailing Patterns Repository Portland URLs: General Conferences Books 93