Object-Oriented Design Patterns Part II

SE464/CS446/ECE452

Object-Oriented Design Patterns Part II Instructor: Krzysztof Czarnecki

1

• These slides are mainly based on: – Tutorial slides by John Vlissides, see http://www.research.ibm.com/designpatterns/pubs/dp-tutorial.pdf

and http://www.research.ibm.com/designpatterns/pubs/dwp-tutorial.pdf • Text © 1994-1999 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

– Some material by Ian Davis and Grant Weddell and P. Dasiewicz 2

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor

• Some more patterns – – – – – – –

Template Method Singleton Builder Prototype Adapter Façade Interpreter

• Observations and Conclusions • Further reading

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

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

5

Iterator (Behavioral)


• 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 6

Iterator (cont'd) • Structure Iterator


Aggregate (Glyph) +createIterator()

Client *

*

*

*

ConcreteAgregate +createIterator()

+first() +next() +isDone() +currentItem()

ConcreteIterator 1

*

{ return ConcreteIterator(this); }

7

Iterator (cont'd)


• 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

8





9

Spelling Checking and 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 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 }

10

Spelling Checking and Hyphenation (cont'd) • SpellingCheckerVisitor © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

– Gets character code from each character glyph • Can define getCharCode operation just on Character class

– Checks words accumulated from character glyphs – Combine with PreorderIterator

11



• Accumulating Words

• Spelling check on each non-alphabetic character

12

Interaction Diagram $a

$b $space

aSpellingChecker

accept(aSpellingChecker)


visit(this) getCharCode()

accept(aSpellingChecker) visit(this) getCharCode()()

Checks completed word 13



• HyphenationVisitor – Gets character code from each character glyph – Examines words accumulated from character glyphs – At potential hyphenation point, inserts a...

14



• 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

15

Visitor (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 over the structure maintain state that's updated during traversal 16

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

Client

ObjectStructure *

*

Element *

1

+accept(in v : Visitor)

** Visitor +VisitConcreteElement1(ConcreteElement1)() +VisitConcreteElement2(ConcreteElement2)()

ConcreteElement1

ConcreteElement2



ConcreteVisitor +VisitConcreteElement1(ConcreteElement1)() +VisitConcreteElement2(ConcreteElement2)()

{ v.visitConcreteElement1(this); }

{ v.visitConcreteElement2(this); }

17

Visitor (cont'd)


• 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

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

19





20

Template Method (Behavioral)


• 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 21

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

AbstractClass +templateMethod() +primitiveOperation1() +primitiveOperation2()

{... primitiveOperation1(); ... primitiveOperation2(); ...}

ConcreteClass +primitiveOperation1() +primitiveOperation2()

22

Template Method (cont'd)


• 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) 23

Template Method (cont'd)


• 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 24





25

Singleton (Creational)


• 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 26

Singleton (cont'd) • Example – Threads may wish to emit error messages – How error messages are handled is not the threads problem – May want to direct error messages to a single shared error message area – Need to avoid conflict when multiple threads concurrently report errors – Easy to change so that each thread has their own error message area if desired 27

Singleton (cont'd)


• Structure Singleton -uniqueInstance : Singleton -singletonData +instance() +singletonOperation() +getSingletonData()

{ return uniqueInstance; }

Clients access Singleton only through its instance method! 28

Singleton (cont'd)


• Consequences + Reduces namespace pollution + Allows controlled access to the singleton object + 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 29

Singleton (cont'd) •

A possible C++ implementation

class Singleton { public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; }; Singleton* Singleton::_instance = 0; Singleton* Singleton::Instance () { if (_instance == 0) { _instance = new Singleton; } return _instance; } 30

Singleton (cont'd) • Subclassing the Singleton class? – Many possible approaches, main problem is installing its unique instance so that clients can use it • possibly use a registry of singletons approach • registry maps between string names and singletons • when instance() needs a singleton, it queries the registry for a singleton by name • instance() not needed to know all possible classes or instances 31

Singleton (cont'd) • Need a common interface for all Singleton classes: class Singleton { public: static void register(const char* name, Singleton*); static Singleton* instance(); protected: static Singleton* lookup(const char* name); private: static Singleton* _instance; static List* _registry; };

32

Singleton (cont'd) • Lazy initialization of _instance: Singleton* Singleton::instance () { if (_instance == 0) { const char* singletonName = getenv("SINGLETON"); // user or environment supplies this at startup _instance = lookup(singletonName); // lookup returns 0 if there's no such singleton } return _instance; }

33

Singleton (cont'd) • Implementation variant – Possibly use its constructor for a Singleton class to register itself – consider the following Singleton subclass: MySingleton::MySingleton() { // ... Singleton::register("MySingleton", this); } // PROBLEM??

– But, constructor is not called until an attempt made to instantiate the class – perhaps define a static instance of MySingleton in file containing the implementation of MySingleton: static MySingleton theSingleton;

– But beware that the order of creation of static objects in C++ is not deterministic – Thus, lazy initialization in instance() might be the best choice 34

Singleton (cont'd)


• Known Uses – Unidraw's Unidraw object – Smalltalk-80 ChangeSet, the set of changes to code – InterViews Session object

35





36

Builder • Intent – Separate the construction of a complex object from its representation so that the same construction process can create different representations

• Applicability – Want to divorce the issue of what is used to build a result from how the result is built – May want to build many different things from the same input – Easy to create and introduce into system new builder classes, if they all have the same external behavior – Essentially, the builder pattern reinforces the importance of polymorphism 37

Builder (cont'd) • Example – Parser identifies types of data tokens traversed within document – Want to tell application what has been seen while traversing document – Don’t want to tell application what to do with this data. Application may format this data, build electronic indices from it, etc. – May want to view document in many concurrent windows and styles 38

Builder (cont'd) • Methods of a builder class provide an interface which allows the builder class to receive in a pre-determined manner the material from which something is to be built, produced or used • The builder also provides a method to return the result of construction if appropriate 39

Builder (cont'd) • Structure - Example

40

Builder (cont'd) • Structure - Example – As the RTFReader parses the RTF document, it uses the TextConverter to perform the conversion – Whenever the RTFReader recognizes an RTF token (either plain text or an RTF control word), it issues a request to the TextConverter to convert the token – TextConverter objects are responsible both for performing the data conversion and for representing the token in a particular format 41

Builder (cont'd) • Structure

42

Builder (cont'd) • Participants – Builder (TextConverter) • specifies an abstract interface for creating parts of a Product object

– ConcreteBuilder (ASCIIConverter, TeXConverter, TextWidgetConverter) • constructs and assembles parts of the product by implementing the Builder interface • defines and keeps track of the representation it creates. • provides an interface for retrieving the product (e.g., GetASCIIText, GetTextWidget)

43

Builder (cont'd) • Participants – Director (RTFReader) • constructs an object using the Builder interface.

– Product (ASCIIText, TeXText, TextWidget) • represents the complex object under construction. ConcreteBuilder builds the product's internal representation and defines the process by which it's assembled • includes classes that define the constituent parts, including interfaces for assembling the parts into the final result

44





45

Prototype • Don’t want to explicitly remember the knowledge of exactly what class an instance and with what parameters should be created when requested • Instead encapsulate this information by holding a dummy instance of the class to be instantiated following a given request • Clone copies of this dummy instance as needed

46

Prototype (cont'd) • Example – Visio has vast numbers of visual symbols stored in template sheets – The symbols can be identified by GUID – The GUID allows the class supporting the representation of that symbol to be loaded – Once loaded the visual symbol can be cloned multiple times – It may appear multiple times in a drawing 47

Prototype (cont'd) • Structure - Example

48

Prototype (cont'd) • Structure – Example – To create a new graphical object, the prototypical instance of the specific graphical class is passed as parameter to the constructor of the GraphicTool class. – The GraphicTool class can then use this prototype to clone a new object and operate on it. – If all the Graphic subclasses support a Clone operation, then the GraphicTool Class can clone any kind of Graphic 49

Prototype (cont'd) • Structure

50

Prototype (cont'd) • Participants – Prototype (Graphic) • declares an interface for cloning itself

– ConcretePrototype (Staff, WholeNote, HalfNote) • implements an operation for cloning itself

– Client (GraphicTool) • creates a new object by asking a prototype to clone itself 51





52

Adapter • Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces • Motivation: When we want to reuse classes in an application that expects a different interface, we do not want to (and often cannot) change the reusable classes to suit our application 53

Adapter (cont’d) • Structure - Example

54

Adapter (cont’d) • Structure using object composition

-lets a single Adapter work with many Adaptees— Adaptee itself and all of its subclasses (if any).

55

Adapter (cont’d) • Structure with multiple inheritance

-commits to a concrete Adaptee class. -won't work when need to adapt a class and all its subclasses. -lets Adapter override some of Adaptee's behavior -introduces only one object, and no additional pointer indirection

56

Adapter (cont’d) • Participants – Target: Defines the application-specific interface that clients use – Client: Collaborates with objects conforming to the target interface – Adaptee: Defines an existing interface that needs adapting – Adapter: Adapts the interface of the adaptee to the target interface 57





58

Facade: intent

• Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

59

Facade: motivation • Structuring a system into subsystems helps reduce complexity. • A common design goal is to minimize the communication and dependencies between subsystems. • Use a facade object to provide a single simplified interface to the more general facilities of a subsystem.

60

Facade: example

61

Facade: structure Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use

62

Facade: structure -need to provide a simple interface to a complex subsystem -a facade can provide a simple default view of the subsystem that is good enough for most clients -clients needing more customizability will need to look beyond the facade

63

Facade: participants • Facade: – Knows which subsystem classes are responsible for a request. – Delegates client requests to appropriate subsystem objects. • Subsystem Classes: – Implement subsystem functionality. – Handle work assigned by the facade object. – Have no knowledge of the facade; that is, they keep no references to it. 64

Façade - Example

65

Façade - Example

66





67

Interpreter: intent and motivation • Want to compute something capable of being expressed in a language. • The computation is performed on structural representation of the language operations to be performed. • Structural objects representing operations have built in knowledge of how to perform their own operation. 68

Interpreter • If a particular kind of problem occurs often enough, then it might be worthwhile to express instances of the problem as sentences in a simple language. • Then you can build an interpreter that solves the problem by interpreting these sentences 69

Interpreter: example • A language statement may be converted to an expression tree of operations to be performed. • Each operation takes as its input the results returned by it’s child expression trees. • Such an expression tree is often called a plan. 70

Interpreter: example • Suppose the following grammar defines the regular expressions: expression ::= literal | alternation | sequence | repetition | '(' expression ')‘ alternation ::= expression '|' expression sequence ::= expression '&' expression repetition ::= expression '*' literal ::= 'a' | 'b' | 'c' | ... { 'a' | 'b' | 'c' | ... }* • The symbol expression is the start symbol, and literal is a terminal symbol defining simple words. 71

Interpreter: example The Interpreter pattern uses a class to represent each grammar rule. Symbols on the right-hand side of the rule are instance variables of these classes

72

Every regular expression defined by this grammar is represented by an abstract syntax tree made up of instances of these classes.

For example, the abstract syntax tree represents the regular expression raining & (dogs | cats) *

73

Interpreter: structure

74

Interpreter: participants • AbstractExpression (RegularExpression) – declares an abstract Interpret operation that is common to all nodes in the abstract syntax tree.

• TerminalExpression (LiteralExpression) – implements an Interpret operation associated with terminal symbols in the grammar. – an instance is required for every terminal symbol in a sentence.

75

Interpreter: participants • NonterminalExpression (AlternationExpression, RepetitionExpression, SequenceExpressions) – one such class is required for every rule R ::= R1 R2 ... Rn in the grammar. – maintains instance variables of type AbstractExpression for each of the symbols R1 through Rn. – implements an Interpret operation for nonterminal symbols in the grammar. Interpret typically calls itself recursively on the variables representing R1 through Rn. 76

Interpreter: participants • Context – contains information that's global to the interpreter.

• Client – builds (or is given) an abstract syntax tree representing a particular sentence in the language that the grammar defines. The abstract syntax tree is assembled from instances of the NonterminalExpression and TerminalExpression classes. – invokes the Interpret operation. 77





78

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 79

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 80

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 81 and black-box categories

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 82 Meyers, Addison-Wesley (December 1995)

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 83

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! 84

Conclusion • Design patterns promote – – – – –

Design reuse Uniform design vocabulary Understanding, restructuring Automation A new way of thinking about design

85





86

(Design) Pattern References • • • • • • • •

The Timeless Way of Building, Alexander; Oxford, 1979; ISBN 0-19502402-8 A Pattern Language, Alexander; Oxford, 1977; ISBN 0-19-501-919-9 Design Patterns, Gamma, et al.; Addison-Wesley, 1995; ISBN 0-20163361-2; CD version ISBN 0-201-63498-8 Pattern-Oriented Software Architecture, Buschmann, et al.; Wiley, 1996; ISBN 0-471-95869-7 Analysis Patterns, Fowler; Addison-Wesley, 1996; ISBN 0-20189542-0 Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997; ISBN 013-476904-X The Design Patterns Smalltalk Companion, Alpert, et al.; AddisonWesley, 1998; ISBN 0-201-18462-1 AntiPatterns, Brown, et al.; Wiley, 1998; ISBN 0-471-19713-0 87

More Books •

Pattern Languages of Program Design (Addison-Wesley) – – – – –

• • • •

Vol. 1, Coplien, et al., eds.; 1995; ISBN 0-201-60734-4 Vol. 2, Vlissides, et al., eds.; 1996; ISBN 0-201-89527-7 Vol. 3, Martin, et al., eds.; 1998; ISBN 0-201-31011-2 Vol. 4, Harrison, et al., eds.; 2000; ISBN 0-201-43304-4 …

Concurrent Programming in Java, Lea; Addison-Wesley, 1997; ISBN 0-201-69581-2 Applying UML and Patterns, Larman; 2nd edition, Prentice Hall, 2002; ISBN 0-13-092569-1 Pattern Hatching: Design Patterns Applied, Vlissides; AddisonWesley, 1998; ISBN 0-201-43293-5 The Pattern Almanac, Rising; Addison-Wesley, 2000; ISBN 0-20161567-3 88

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)

89

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

90

Conferences • PLoP: Pattern Languages of Programs, Monticello, Illinois, USA (September) • ChiliPLoP, Carefree, USA (March) • EuroPLoP, Kloster Irsee, Germany (July) • KoalaPLoP, Melbourne, Australia (May) • … • See http://hillside.net/conferences for up-tothe-minute information. 91

Mailing Lists • • • • • • • •

[email protected]: present and refine patterns [email protected]: general discussion on patterns [email protected]: discussion on Design Patterns [email protected]: discussion on Pattern-Oriented Software Architecture [email protected]: discussion on user interface design patterns [email protected]: discussion on patterns for business processes [email protected]: discussion on patterns for distributed systems See http://hillside.net/patterns/mailing.htm for an up-to-date list. 92

URLs • General – http://hillside.net – http://www.research.ibm.com/designpatterns

• Conferences – http://hillside.net/conferences/

• Books – http://hillside.net/patterns/books/

• Mailing Lists – http://hillside.net/patterns/mailing.html

• Portland Patterns Repository – http://c2.com/ppr/index.html

93

Object-Oriented Design Patterns Part II

Object-Oriented Design Patterns Part II

Suggest Documents