GoF Design Patterns

Slide 1: An Introduction to Design Patterns Douglas C. Schmidt Vanderbilt University schmidt@dre.vanderbilt.edu Based on material produced by John Vlissides 1

Slide 2: Overview Part I: Motivation & Concept the issue  what design patterns are  what they’re good for  how we develop & categorize them  2

Slide 3: Overview (cont’d) Part II: Application use patterns to design a document editor  demonstrate usage & benefits  Part III: Wrap-Up observations, caveats, & conclusion  3

Slide 4: Part I: Motivation & Concept OOD methods emphasize design notations Fine for specification, documentation But OOD is more than just drawing diagrams Good draftsmen  good designers Good OO designers rely on lots of experience At least as important as syntax Most powerful reuse is design reuse Match problem to design experience 4

Slide 5: Part I: Motivation & Concept (cont’d) Recurring Design Structures OO systems exhibit recurring structures that promote abstraction  flexibility  modularity  elegance  Therein lies valuable design knowledge Problem: capturing, communicating, & applying this knowledge 5

Slide 6: Part I: Motivation & Concept (cont’d) A Design Pattern… • abstracts a recurring design structure • comprises class and/or object dependencies  structures  interactions  conventions  • names & specifies the design structure explicitly • distills design experience 6

Slide 7: Part I: Motivation & Concept (cont’d) Four Basic Parts  Name  Problem (including “forces”)  Solution  Consequences & trade-offs of application Language- & implementation-independent A “micro-architecture” Adjunct to existing methodologies (RUP, Fusion, SCRUM, etc.) 7

Slide 8: Part I: Motivation & Concept (cont’d) Example: OBSERVER 8

Slide 9: Part I: Motivation & Concept (cont’d) Goals Codify good design distill & generalize experience  aid to novices & experts alike  Give design structures explicit names common vocabulary  reduced complexity  greater expressiveness  Capture & preserve design information articulate design decisions succinctly  improve documentation  Facilitate restructuring/refactoring patterns are interrelated  9 additional flexibility 

Slide 10: Part I: Motivation & Concept (cont’d) Design Space for GoF Patterns Scope: domain over which a pattern applies Purpose: reflects what a pattern does 10

Slide 11: Part I: Motivation & Concept (cont’d) Design Pattern Template (1st half) NAME scope purpose Intent short description of the pattern & its purpose Also Known As short description of the pattern & its purpose Motivation motivating scenario demonstrating pattern’s use Applicability circumstances in which pattern applies Structure graphical representation of the pattern using modified OMT notation Participants participating classes and/or objects & their responsibilities 11

Slide 12: Part I: Motivation & Concept (cont’d) Design Pattern Template (2nd half) ... Collaborations how participants cooperate to carry out their responsibilities Consequences the results of application, benefits, liabilities Implementation pitfalls, hints, techniques, plus language-dependent issues Sample Code sample implementations in C++, Java, C#, Smalltalk, C, etc. Known Uses examples drawn from existing systems Related Patterns discussion of other patterns that relate to this one 12

Slide 13: Part I: Motivation & Concept (cont’d) Modified UML/OMT Notation 13

Slide 14: Motivation & Concept (cont’d) OBSERVER object behavioral Intent define a one-to-many dependency between objects so that when one object changes state, all dependents are notified & updated Applicability an abstraction has two aspects, one dependent on the other  a change to one object requires changing untold others  an object should notify unknown other objects  Structure 14

Slide 15: Motivation & Concept (cont’d) OBSERVER (cont’d) object behavioral Consequences + modularity: subject & observers may vary independently + extensibility: can define & add any number of observers + customizability: different observers offer different views of subject – unexpected updates: observers don’t know about each other – update overhead: might need hints or filtering Implementation subject-observer mapping  dangling references  update protocols: the push & pull models  registering modifications of interest explicitly  Known Uses Smalltalk Model-View-Controller (MVC)  InterViews (Subjects & Views, Observer/Observable)  Andrew (Data Objects & Views)  15 Mailing lists 

Slide 16: Part I: Motivation & Concept (cont’d) Benefits of Patterns • Design reuse • Uniform design vocabulary • Enhance understanding, restructuring, & team communication • Basis for automation • Transcends language-centric biases/myopia • Abstracts away from many unimportant details 16

Slide 17: Part I: Motivation & Concept (cont’d) Liabilities of Patterns • Require significant tedious & error-prone human effort to handcraft pattern implementations design reuse • Can be deceptively simple uniform design vocabulary • Leaves some important details unresolved 17

Slide 18: Part II: Application: Document Editor (Lexi) 7 Design Problems  Document structure  Formatting  Embellishment  Multiple look & feels  Multiple window systems  User operations  Spelling checking & hyphenation 18

Slide 19: Document Structure Goals: present document’s visual aspects  drawing, hit detection, alignment  support physical structure  (e.g., lines, columns) Constraints/forces: treat text & graphics uniformly  no distinction between one & many  19

Slide 20: Document Structure (cont’d) Solution: Recursive Composition 20

Slide 21: Document Structure (cont’d) Object Structure 21

Slide 22: Document Structure (cont’d) Glyph Base class for composable graphical objects Basic interface: Task Operations appearance void draw(Window) hit detection boolean intersects(Coord, Coord) structure void insert(Glyph) void remove(Glyph) Glyph child(int) Glyph parent() Subclasses: Character, Image, Space, Row, Column 22

Slide 23: Document Structure (cont’d) Glyph Hierarchy Note the inherent recursion in this hierarchy  i.e., a Row is a Glyph & a Row also has Glyphs! 23

Slide 24: Document Structure (cont’d) COMPOSITE object structural Intent treat individual objects & multiple, recursively-composed objects uniformly Applicability objects must be composed recursively, and no distinction between individual & composed elements, and objects in structure can be treated uniformly Structure 24

Slide 25: Document Structure (cont’d) COMPOSITE (cont’d) object structural Consequences + uniformity: treat components the same regardless of complexity + extensibility: new Component subclasses work wherever old ones do – overhead: might need prohibitive numbers of objects Implementation do Components know their parents?  uniform interface for both leaves & composites?  don’t allocate storage for children in Component base class  responsibility for deleting children  Known Uses ET++ Vobjects  InterViews Glyphs, Styles  Unidraw Components, MacroCommands  25

Slide 26: Formatting Goals: automatic linebreaking, justification  Constraints/forces: support multiple linebreaking algorithms  don’t tightly couple these algorithms with  the document structure 26

Slide 27: Formatting (cont’d) Solution: Encapsulate Linebreaking Strategy Compositor base class abstracts linebreaking algorithm  subclasses for specialized algorithms,  e.g., SimpleCompositor, TeXCompositor Composition composite glyph  supplied a compositor & leaf glyphs  creates row-column structure as directed by  compositor 27

Slide 28: Formatting (cont’d) New Object Structure Generated in accordance with compositor strategies & do not affect contents of leaf glyphs 28

Slide 29: Formatting (cont’d) STRATEGY object behavioral Intent define a family of algorithms, encapsulate each one, & make them interchangeable to let clients & algorithms vary independently Applicability when an object should be configurable with one of many algorithms, and all algorithms can be encapsulated, and one interface covers all encapsulations Structure 29

Slide 30: Formatting (cont’d) STRATEGY (cont’d) object behavioral Consequences + greater flexibility, reuse + can change algorithms dynamically – strategy creation & communication overhead – inflexible Strategy interface – semantic incompatibility of multiple strategies used together Implementation exchanging information between a Strategy & its context  static strategy selection via templates  Known Uses InterViews text formatting  RTL register allocation & scheduling strategies  ET++SwapsManager calculation engines  See Also 30 Bridge pattern (object structural) 

Slide 31: Embellishment Goals: add a frame around text composition  add scrolling capability  Constraints: embellishments should be reusable without  subclassing, i.e., so they can be added dynamically at runtime should go unnoticed by clients  31

Slide 32: Embellishment (cont’d) Solution: “Transparent” Enclosure Monoglyph base class for glyphs having one child  operations on MonoGlyph pass through to child  MonoGlyph subclasses: Frame: adds a border of specified width  Scroller: scrolls/clips child, adds scrollbars  32

Slide 33: Embellishment (cont’d) MonoGlyph Hierarchy void Frame::draw (Window &w) { // Order may be important! MonoGlyph::draw (w); void MonoGlyph::draw (Window &w) { drawFrame (w); component->draw (w); } } 33

Slide 34: Embellishment (cont’d) New Object Structure 34

Slide 35: Embellishment (cont’d) DECORATOR object structural Intent augment objects with new responsibilities Applicability when extension by subclassing is impractical  for responsibilities that can be withdrawn  Structure 35

Slide 36: Embellishment (cont’d) DECORATOR (cont’d) object structural Consequences + responsibilities can be added/removed at run-time + avoids subclass explosion + recursive nesting allows multiple responsibilities – interface occlusion – identity crisis Implementation interface conformance  use a lightweight, abstract base class for Decorator  heavyweight base classes make Strategy more attractive  Known Uses embellishment objects from most OO-GUI toolkits  ParcPlace PassivityWrapper  InterViews DebuggingGlyph  36

Slide 37: Multiple Look & Feels Goals: support multiple look & feel standards  generic, Motif, Swing, PM, Macintosh,  Windows, ... extensible for future standards  Constraints: don’t recode existing widgets or clients  switch look & feel without recompiling  37

Slide 38: Multiple Look & Feels (cont’d) Solution: Abstract Object Creation Instead of Scrollbar *sb = new MotifScrollbar(); use Scrollbar *sb = factory->createScrollbar(); where factory is an instance of MotifFactory • BTW, this begs the question of who created the factory! 38

Slide 39: Multiple Look & Feels (cont’d) Factory Interface • defines “manufacturing interface” • subclasses produce specific products • subclass instance chosen at run-time // This class is essentially a Java interface class Factory { public: Scrollbar *createScrollbar() = 0; Menu *createMenu() = 0; ... }; 39

Slide 40: Multiple Look & Feels (cont’d) Factory Structure Scrollbar *MotifFactory::createScrollBar () { return new MotifScrollbar(); } Scrollbar *PMFactory::createScrollBar () { return new PMScrollbar(); 40 }

Slide 41: Multiple Look & Feels (cont’d) ABSTRACT FACTORY object creational Intent create families of related objects without specifying class names Applicability when clients cannot anticipate groups of classes to instantiate Structure 41

Slide 42: Multiple Look & Feels (cont’d) ABSTRACT FACTORY (cont’d) object creational Consequences + flexibility: removes type dependencies from clients + abstraction: hides product’s composition – hard to extend factory interface to create new products Implementation parameterization as a way of controlling interface size  configuration with Prototypes, i.e., determines who creates the  factories Known Uses InterViews Kits  ET++ WindowSystem  AWT Toolkit  42

Slide 43: Multiple Window Systems Goals: make composition appear in a window  support multiple window systems  Constraints: minimize window system dependencies in  application & framework code 43

Slide 44: Multiple Window Systems (cont’d) Solution: Encapsulate Implementation Dependencies Window user-level window abstraction  displays a glyph (structure)  window system-independent  task-related subclasses  (e.g., IconWindow, PopupWindow) 44

Slide 45: Multiple Window Systems (cont’d) Window Interface class Window { public: ... void iconify(); // window-management void raise(); ... void drawLine(...); // device-independent void drawText(...); // graphics interface ... }; 45

Slide 46: Multiple Window Systems (cont’d) Window uses a WindowRep • abstract implementation interface • encapsulates window system dependencies • window systems-specific subclasses (e.g., XWindowRep, SunWindowRep) An Abstract Factory can produce the right WindowRep! 46

Slide 47: Multiple Window Systems (cont’d) Window/WindowRep Structure void Character::draw (Window &w) { w.drawText(...); } void Window::drawText (...) { rep->deviceText(...); } void XWindowRep::deviceText (...) { XText(...); 47 }

Slide 48: Multiple Window Systems (cont’d) New Object Structure Note the decoupling between the logical structure of the contents in a window from the physical rendering of the contents in the window 48

Slide 49: Multiple Window Systems (cont’d) BRIDGE object structural Intent separate a (logical) abstraction interface from its (physical) implementation(s) Applicability when interface & implementation should vary independently  require a uniform interface to interchangeable class hierarchies  Structure 49

Slide 50: Multiple Window Systems (cont’d) BRIDGE (cont’d) object structural Consequences + abstraction interface & implementation are independent + implementations can vary dynamically – one-size-fits-all Abstraction & Implementor interfaces Implementation sharing Implementors & reference counting  creating the right implementor  Known Uses ET++ Window/WindowPort  libg++ Set/{LinkedList, HashTable}  AWT Component/ComponentPeer  50

Slide 51: User Operations Goals: support execution of user operations  support unlimited-level undo  Constraints: scattered operation implementations  must store undo state  not all operations are undoable  51

Slide 52: User Operations (cont’d) Solution: Encapsulate Each Request A Command encapsulates an operation (execute())  an inverse operation (unexecute())  a operation for testing reversibility  (boolean reversible()) state for (un)doing the operation  Command may implement the operations itself, or  delegate them to other object(s)  52

Slide 53: User Operations (cont’d) Command Hierarchy void PasteCommand::execute () { // do the paste } void CopyCommand::execute () { // do the copy } void MenuItem::clicked () { command->execute(); } 53

Slide 54: User Operations (cont’d) List of Commands = Execution History Undo: Redo: unexecute() unexecute() execute() cmd cmd past future future past 54

Slide 55: User Operations (cont’d) COMMAND object behavioral Intent encapsulate the request for a service Applicability to parameterize objects with an action to perform  to specify, queue, & execute requests at different times  for multilevel undo/redo  Structure 55

Slide 56: User Operations (cont’d) COMMAND (cont’d) object behavioral Consequences + abstracts executor of a service + supports arbitrary-level undo-redo + composition yields macro-commands – might result in lots of trivial command subclasses Implementation copying a command before putting it on a history list  handling hysteresis  supporting transactions  Known Uses InterViews Actions  MacApp, Unidraw Commands  JDK’s UndoableEdit, AccessibleAction 56 

Slide 57: Spelling Checking & Hyphenation Goals: analyze text for spelling errors  introduce potential hyphenation sites  Constraints: support multiple algorithms  don’t tightly couple algorithms with  document structure 57

Slide 58: Spelling Checking & Hyphenation (cont’d) Solution: Encapsulate Traversal Iterator encapsulates a  traversal algorithm without exposing representation details to callers uses Glyph’s child  enumeration operation This is an example  of a “preorder iterator” 58

Slide 59: Spelling Checking & Hyphenation (cont’d) ITERATOR object behavioral Intent access elements of a container without exposing its representation Applicability require multiple traversal algorithms over a container  require a uniform traversal interface over different containers  when container classes & traversal algorithm must vary  independently Structure 59

Slide 60: Spelling Checking & Hyphenation (cont’d) ITERATOR (cont’d) object behavioral Iterators are used heavily in the C++ Standard Template Library (STL) int main (int argc, char *argv[]) { vector<string> args; for (int i = 0; i < argc; i++) args.push_back (string (argv[i])); for (vector<string>::iterator i (args.begin ()); i != args.end (); i++) cout << *i; The same iterator pattern can be applied to any STL container! cout << endl; return 0; 60 }

Slide 61: Spelling Checking & Hyphenation (cont’d) ITERATOR (cont’d) object behavioral Consequences + flexibility: aggregate & traversal are independent + multiple iterators & multiple traversal algorithms – additional communication overhead between iterator & aggregate Implementation internal versus external iterators  violating the object structure’s encapsulation  robust iterators  Known Uses C++ STL iterators  JDK Enumeration, Iterator  Unidraw Iterator 61 

Slide 62: Spelling Checking & Hyphenation (cont’d) Visitor • defines action(s) at each step of traversal • avoids wiring action(s) into Glyphs • iterator calls glyph’s accept(Visitor) at each node • accept() calls back on visitor (a form of “static polymorphism” based on method overloading by type) void Character::accept (Visitor &v) { v.visit (*this); } class Visitor { public: virtual void visit (Character &); virtual void visit (Rectangle &); virtual void visit (Row &); // etc. for all relevant Glyph subclasses 62 };

Slide 63: Spelling Checking & Hyphenation (cont’d) SpellingCheckerVisitor • gets character code from each character glyph Can define getCharCode() operation just on Character() class • checks words accumulated from character glyphs • combine with PreorderIterator class SpellCheckerVisitor : public Visitor { public: void visit (Character &); void visit (Rectangle &); void visit (Row &); // etc. for all relevant Glyph subclasses }; 63

Slide 64: Spelling Checking & Hyphenation (cont’d) Accumulating Words Spelling check performed when a nonalphabetic character it reached 64

Slide 65: Spelling Checking & Hyphenation (cont’d) Interaction Diagram • The iterator controls the order in which accept() is called on each glyph in the composition • accept() then “visits” the glyph to perform the desired action • The Visitor can be subclassed to implement various desired actions 65

Slide 66: Spelling Checking & Hyphenation (cont’d) HyphenationVisitor • gets character code from each character glyph • examines words accumulated from character glyphs • at potential hyphenation point, inserts a... class HyphenationVisitor : public Visitor { public: void visit (Character &); void visit (Rectangle &); void visit (Row &); // etc. for all relevant Glyph subclasses }; 66

Slide 67: Spelling Checking & Hyphenation (cont’d) Discretionary Glyph • looks like a hyphen when at end of a line • has no appearance otherwise • Compositor considers its presence when determining linebreaks 67

Slide 68: Spelling Checking & Hyphenation (cont’d) VISITOR object behavioral Intent centralize operations on an object structure so that they can vary independently but still behave polymorphically Applicability when classes define many unrelated operations  class relationships of objects in the structure rarely change,  but the operations on them change often algorithms keep state that’s updated during traversal  Structure 68

Slide 69: Spelling Checking & Hyphenation (cont’d) VISITOR (cont’d) object behavioral Consequences + flexibility: visitor & object structure are independent + localized functionality – circular dependency between Visitor & Element interfaces – Visitor brittle to new ConcreteElement classes Implementation double dispatch  general interface to elements of object structure  Known Uses ProgramNodeEnumerator in Smalltalk-80 compiler  IRIS Inventor scene rendering  TAO IDL compiler to handle different backends  69

Slide 70: Part III: Wrap-Up Observations Patterns are applicable in all stages of the OO lifecycle design & reviews  realization & documentation  reuse & refactoring  Patterns permit design at a more abstract level treat many class/object interactions as a unit  often beneficial after initial design  targets for class refactorings  Variation-oriented design consider what design aspects are variable  identify applicable pattern(s)  vary patterns to evaluate tradeoffs  70 repeat 

Slide 71: Part III: Wrap-Up (cont’d) But… Don’t apply them blindly Added indirection can yield increased complexity, cost Resist branding everything a pattern Articulate specific benefits Demonstrate wide applicability Find at least three existing examples from code other than your own! Pattern design even harder than OO design! 71

Slide 72: Part III: Wrap-Up (cont’d) Concluding Remarks • design reuse • uniform design vocabulary • understanding, restructuring, & team communication • provides the basis for automation • a “new” way to think about design 72

Slide 73: Pattern References Books The Timeless Way of Building, Alexander, ISBN 0-19-502402-8 A Pattern Language, Alexander, 0-19-501-919-9 Design Patterns, Gamma, et al., 0-201-63361-2 CD version 0-201-63498-8 Pattern-Oriented Software Architecture, Buschmann, et al., 0-471-95869-7 Pattern-Oriented Software Architecture, Vol. 2, Schmidt, et al., 0-471-60695-2 Pattern-Oriented Software Architecture, Vol. 3, Jain & Kircher, et al., 0-470-84525-2 Analysis Patterns, Fowler; 0-201-89542-0 73

Slide 74: Pattern References (cont’d) More Books Concurrent Programming in Java, 2nd ed., Lea, 0-201-31009- 0 Pattern Languages of Program Design Vol. 1, Coplien, et al., eds., ISBN 0-201-60734-4 Vol. 2, Vlissides, et al., eds., 0-201-89527-7 Vol. 3, Martin, et al., eds., 0-201-31011-2 Vol. 4, Harrison, et al., eds., 0-201-43304-4 AntiPatterns, Brown, et al., 0-471-19713-0 Applying UML & Patterns, 2nd ed., Larman, 0-13-092569-1 Pattern Hatching, Vlissides, 0-201-43293-5 The Pattern Almanac 2000, Rising, 0-201-61567-3 74

Slide 75: Pattern References (cont’d) Even More Books Small Memory Software, Noble & Weir, 0-201-59607-5 Microsoft Visual Basic Design Patterns, Stamatakis, 1-572- 31957-7 Smalltalk Best Practice Patterns, Beck; 0-13-476904-X The Design Patterns Smalltalk Companion, Alpert, et al., 0-201-18462-1 Modern C++ Design, Alexandrescu, ISBN 0-201-70431-5 Building Parsers with Java, Metsker, 0-201-71962-2 75

Slide 76: Pattern References (cont’d) New Books Core J2EE Patterns, Alur, et al., 0-130-64884-1 Design Patterns Explained, Shalloway & Trott, 0-201- 71594-5 The Joy of Patterns, Goldfedder, 0-201-65759-7 The Manager Pool, Olson & Stimmel, 0-201-72583-5 76

Slide 77: Pattern References (cont’d) Early Papers “Object-Oriented Patterns,” P. Coad; Comm. of the ACM, 9/92 “Documenting Frameworks using Patterns,” R. Johnson; OOPSLA ’92 “Design Patterns: Abstraction & Reuse of Object-Oriented Design,” Gamma, Helm, Johnson, Vlissides, ECOOP ’93 Articles Java Report, Java Pro, JOOP, Dr. Dobb’s Journal, Java Developers Journal, C++ Report 77

Slide 78: Pattern-Oriented Conferences PLoP 2006: Pattern Languages of Programs October 2006, Collocated with OOPSLA EuroPLoP 2006, July 2006, Kloster Irsee, Germany … See hillside.net/conferencesnavigation.htm for up-to-the-minute info. 78

Slide 79: Mailing Lists patterns@cs.uiuc.edu: present & refine patterns patterns-discussion@cs.uiuc.edu: general discussion gang-of-4-patterns@cs.uiuc.edu: discussion on Design Patterns siemens-patterns@cs.uiuc.edu: discussion on Pattern-Oriented Software Architecture ui-patterns@cs.uiuc.edu: discussion on user interface patterns business-patterns@cs.uiuc.edu: discussion on patterns for business processes ipc-patterns@cs.uiuc.edu: discussion on patterns for distributed systems See http://hillside.net/patterns/mailing.htm for an up-to-date list. 79