Traditional Design Patterns -- II

Transcription

1 Traditional Design Patterns -- II These slides are mainly based on: Tutorial slides by John Vlissides, see and Text by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Diagrams 1995 by Addison-Wesley Publishing Company Note: Compared to the original tutorial by John Vlissides, the diagram notation have been upgraded from OMT to UML and some text has been updated 1

2 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 2

3 Spelling Checking and Hyphenation E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Goals: Analyze text for spelling errors Introduce potential hyphenation sites Constraints: Support multiple algorithms Don't mix up with document structure 3

4 Solution: Encapsulate traversal E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Iterator Encapsulates a traversal algorithm Uses Glyph's child enumeration operation 4

5 Iterator (Behavioral) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Intent Access elements of an aggregate sequentially without exposing its representation Applicability Require multiple traversal algorithms over an aggregate Require a uniform traversal interface over different aggregates When aggregate classes and traversal algorithm must vary independently 5

6 Iterator (cont'd) Structure E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 6

7 Iterator Examle import java.util.*; class IntSet { private Hashtable ht = new Hashtable(); public static class Iterator { private IntSet set; private Enumeration e; private Integer current; public Iterator( IntSet in ) { set = in; } public void first() { e = set.ht.keys(); next(); } public boolean isdone() { return current == null; } public int currentitem() { return current.intvalue(); } public void next() { try { current = (Integer) e.nextelement(); } catch (NoSuchElementException e) { current = null; } } } public void add( int in ) { ht.put( new Integer( in ), "null" ); } public boolean ismember( int i ) { return ht.containskey(new Integer(i)); } public Hashtable gethashtable() { return ht; } public Iterator createiterator() { return new Iterator( this ); } } 7

8 Iterator Example class IteratorDemo { public static void main( String[] args ) { IntSet set = new IntSet();. // Code to add elements to the set and other code } } // Clients ask the collection object to create many iterator objects IntSet.Iterator it1 = set.createiterator(); IntSet.Iterator it2 = set.createiterator(); // Clients use the first(), isdone(), next(), currentitem() protocol System.out.print( "\niterator: " ); for ( it1.first(), it2.first();! it1.isdone(); it1.next(), it2.next() ) System.out.print( it1.currentitem() + " " + it2.currentitem() + " " ); System.out.print( "\nenumeration: " ); for (Enumeration e = set.gethashtable().keys(); e.hasmoreelements(); ) System.out.print( e.nextelement() + " " ); System.out.println(); 8

9 Iterator (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Consequences + Flexibility: aggregate and traversal are independent + Multiple iterators multiple traversal algorithms Additional communication overhead between iterator and aggregate Implementation Internal versus external iterators Violating the object structure's encapsulation Robust iterators Known Uses Penpoint traversal driver/slave InterViews ListItr Unidraw Iterator 9

10 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 10

11 Spelling Checking and Hyphenation (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 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 void Character.accept (Visitor v) { v.visit(this); } interface Visitor { void visit(character); void visit(rectangle); void visit(row); // etc. for all relevant Glyph subclasses } 11

12 Spelling Checking and Hyphenation (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 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 12

13 Spelling Checking and Hyphenation Accumulating Words (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Spelling check on each non-alphabetic character 13

14 Interaction Diagram E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 14

15 Spelling Checking and Hyphenation (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley HyphenationVisitor Gets character code from each character glyph Examines words accumulated from character glyphs At potential hyphenation point, inserts a... 15

16 Spelling Checking and Hyphenation (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Discretionary glyph Looks like a hyphen when it falls at the end of a line Has no appearance otherwise Compositor considers its presence when determining linebreaks 16

17 Visitor (Behavioral) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 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 over the structure maintain state that's updated during traversal 17

18 Visitor (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Consequences + Flexibility: visitor and object structure are independent + Localized functionality Circular dependency between Visitor and Element interfaces Visitor brittle to new ConcreteElement classes Implementation Double dispatch Overloading visit operations Catch-all operation General interface to elements of object structure Known Uses ProgramNodeEnumerator in Smalltalk-80 compiler IRIS Inventor scene rendering 18

19 Visitor (cont'd) Structure E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 19

20 Example A Printing Visitor public class SomeContainer implements Container { public void accept (Visitor visitor) { } for each Object i in this container{ visitor.visit (i); if (visitor.isdone(this)) break; } } //... public class PrintingVisitor extends AbstractVisitor { public void visit (Object object) { System.out.println (object); } //... } // // in another class... Container c = new SomeContainer (); //... c.accept (new PrintingVisitor ()); Definition of SomeContainer and of the accept method Use of visitor 20

21 Editor Example Summary Document Structure Composite Formatting Strategy Embellishment Decorator Multiple Look&Feels Abstract Factory (Multiple window systems) Bridge (User operations) Command Spelling checking & hyphenation Iterator & Visitor 21

22 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 22

23 Template Method (Behavioral) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Intent Define the skeleton of an algorithm in an operation, deferring some steps to subclasses Applicability To implement invariant aspects of an algorithm once and let subclasses define variant parts To localize common behavior in a class to increase code reuse To control subclass extensions 23

24 Template Method (cont'd) Structure E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 24

25 Template Method (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Consequences + Leads to inversion of control ( Hollywood principle : don't call us we'll call you) + Promotes code reuse + Lets you enforce overriding rules Must subclass to specialize behavior Implementation Virtual vs. non-virtual template method Few vs. lots of primitive operations Naming conventions (do- prefix) Known Uses Just about all object-oriented systems (especially frameworks) 25

26 Template Method (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Typical implementation: public abstract class Node { public final void streamout (OutputStream out) { if (isreadable()) { dostreamout(out); } else { dowarning(unreadablewarning); } } //... isreadable, dostreamout, and dowarning are primitive operations 26

27 Template Method - Example 27

28 Template Method - Example class Account { public: void Transaction(float amount); void virtual TransactionSubpartA(); void virtual TransactionSubpartB(); void virtual TransactionSubpartC(); } void Account::Transaction(float amount) { TransactionSubpartA(); TransactionSubpartB(); TransactionSubpartC(); // EvenMoreCode; } class JuniorAccount : public Account { public: void virtual TransactionSubpartA(); } class SavingsAccount : public Account { public: void virtual TransactionSubpartC(); } // Client code Account* customer; customer = JunionAccount(); customer->transaction(amount); 28

29 Singleton (Creational) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Intent Ensure a class only ever has one instance, and provide a global point of access to it. Applicability When there must be exactly one instance of a class, and it must be accessible from a well-known access point When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code 29

30 Singleton (cont'd) Structure E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley 30

31 Singleton (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Consequences + Reduces namespace pollution + Makes it easy to change your mind and allow more than one instance + Allow extension by subclassing Same drawbacks of a global if misused Implementation may be less efficient than a global Concurrency pitfalls Implementation Static instance operation Registering the singleton instance 31

32 Singleton (cont'd) E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Known Uses Unidraw's Unidraw object Smalltalk-80 ChangeSet, the set of changes to code InterViews Session object 32

33 Singleton - Example class Singleton { public: }; static Singleton* Instance(); protected: Singleton(); Singleton(const Singleton&); Singleton& operator= (const Singleton&) private: static Singleton* pinstance; Singleton* Singleton::pinstance = 0; // initialize pointer Singleton* Singleton::Instance () { if (pinstance == 0) // is it the first call? { pinstance = new Singleton; // create sole instance } return pinstance; // address of sole instance } Singleton::Singleton() { //... perform necessary instance initializations } 33

34 Singleton - Example // Client code Singleton *p1 = Singleton::Instance(); Singleton *p2 = p1->instance(); Singleton & ref = * Singleton::Instance(); Although the above example uses a single instance, modifications to the function Instance() may permit a variable number of instances. For example, you can design a class that allows up to three instances. 34

35 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 35

36 Façade E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Façade 36

37 Façade 37

38 Façade - Example 38

39 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 39

40 Inheritance vs. Object Composition Object composition + Provides for clean separation between components through interfaces + Allows for dynamic composition + Allows for flexible mixing and matching of features Has the overhead of forwarding Suffers from the identity crisis Leads to more fragmentation Inheritance + No explicit forwarding necessary Close coupling between a class and its base class Inheritance hierarchies are static and cannot be reconfigured at runtime Adding features through subclassing may lead to a combinatorial explosion Beware of overusing inheritance inheritance is not always the best choice Deep inheritance hierarchy (6 levels and more) in your application is a red flag 40

41 Implementation vs. interface inheritance Implementation inheritance inheriting implementation of methods Is a convenient reuse mechanism, but Introduces high coupling Changing a superclass may brake all subclasses ( fragile base class problem ) Interface inheritance inheriting interface but no implementation (e.g., inheritance involving abstract classes in C++ and interfaces in Java) Does not suffer from the problems of implementation inheritance Subtyping and interface inheritance are more important than implementation inheritance Consider declaring the type of variables to be interfaces rather than concrete classes 41

42 OO Frameworks A framework consists of a set of cooperating classes embodying a design for a family of applications. There are different categories of frameworks: White-box frameworks are reused by subclassing, which usually requires understanding the implementation of the framework to some degree Template method is one of the main mechanisms for white-box frameworks Black-box framework is reused by parameterizing and assembling framework objects. Black-box frameworks hide their implementation from their users Black-box frameworks make heavy use of patterns based on object composition such as decorator and strategy. Many practical frameworks fall somewhere between the white-box and black-box categories 42

43 Patterns at Different Levels Applicable in most stages of the OO lifecycle Analysis, design, implementation, reviews, documentation, reuse, and refactoring Analysis patterns Typical solutions to recuring anlysis problems See Analysis Patterns, Fowler; Addison-Wesley, 1996 Architectural patterns See POSA Design patterns Most GoF design patterns are applicable both at the architectural and detailed design Idioms Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997 Concurrent Programming in Java, Lea; Addison-Wesley, 1997 Advanced C++, Coplien, Addison-Wesley, 1992 Effective C++: 50 Specific Ways to Improve Your Programs and Design (2nd Edition), Scott Meyers, Addison-Wesley, (September 1997) More Effective C++: 35 New Ways to Improve Your Programs and Designs, Scott Meyers, Addison-Wesley (December 1995) 43

44 Observations 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 Repeat 44

45 But... Resist branding everything a pattern Articulate specific benefits Demonstrate wide applicability Find at least two existing examples Don't apply them blindly Added indirection increased complexity, cost Pattern design even harder than OOD! 45

46 Overall Notes Design patterns promote Design reuse Uniform design vocabulary Understanding, restructuring Automation A new way of thinking about design 46

47 Overview Example: WYSIWYG Editor (Cont'd) Spelling checking & hyphenation Iterator Visitor Some more patterns Template Method Singleton Façade Observations and Conclusions Further reading 47

48 (Design) Pattern References The Timeless Way of Building, Alexander; Oxford, 1979; ISBN A Pattern Language, Alexander; Oxford, 1977; ISBN Design Patterns, Gamma, et al.; Addison-Wesley, 1995; ISBN ; CD version ISBN Pattern-Oriented Software Architecture, Buschmann, et al.; Wiley, 1996; ISBN Analysis Patterns, Fowler; Addison-Wesley, 1996; ISBN Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997; ISBN X The Design Patterns Smalltalk Companion, Alpert, et al.; Addison- Wesley, 1998; ISBN AntiPatterns, Brown, et al.; Wiley, 1998; ISBN

49 More Books Pattern Languages of Program Design (Addison-Wesley) Vol. 1, Coplien, et al., eds.; 1995; ISBN Vol. 2, Vlissides, et al., eds.; 1996; ISBN Vol. 3, Martin, et al., eds.; 1998; ISBN Vol. 4, Harrison, et al., eds.; 2000; ISBN Concurrent Programming in Java, Lea; Addison-Wesley, 1997; ISBN Applying UML and Patterns, Larman; 2 nd edition, Prentice Hall, 2002; ISBN Pattern Hatching: Design Patterns Applied, Vlissides; Addison- Wesley, 1998; ISBN The Pattern Almanac, Rising; Addison-Wesley, 2000; ISBN

50 More Books Advanced C++, Coplien, Addison-Wesley, 1992 Effective C++: 50 Specific Ways to Improve Your Programs and Design (2nd Edition), Scott Meyers, Addison-Wesley, (September 1997) More Effective C++: 35 New Ways to Improve Your Programs and Designs, Scott Meyers, Addison-Wesley (December 1995) 50

51 Early Papers Object-Oriented Patterns, P. Coad; Comm. of the ACM, 9/92 Documenting Frameworks using Patterns, R. Johnson; OOPSLA '92 Design Patterns: Abstraction and Reuse of Object-Oriented Design, Gamma, Helm, Johnson, Vlissides, ECOOP '93. Columns: C++ Report, Dr. Dobbs Sourcebook, JOOP, ROAD 51

52 Conferences PLoP: Pattern Languages of Programs, Monticello, Illinois, USA (September) EuroPLoP, Kloster Irsee, Germany (July) ChiliPLoP 2000, March 2000, Wickenburg, Arizona, USA KoalaPLoP 2000, May 2000, Melbourne, Australia See for upto-the-minute information. 52

53 Mailing Lists present and refine patterns general discussion on patterns discussion on Design Patterns discussion on Pattern-Oriented Software Architecture discussion on user interface design patterns discussion on patterns for business processes discussion on patterns for distributed systems See for an up-to-date list. 53

54 URLs General Conferences Books Mailing Lists Portland Patterns Repository 54