History Objectives
and the relevance of design patterns Detailed coverage of some popular existing patterns
a simple example: The Proxy pattern case study
The Proxy Pattern
Context:
situations in which access to an object should be controlled
In graphical application, protect objects whose display is expensive or slow (e.g., a picture) In network application, facilitate access to distributed objects (e.g., make it easy for a client to find a server) In OS application, protect objects from unauthorized access
Design Patterns for OO Development NOTE: Im still working on slides 52-74
1
2
3
The Proxy Pattern (contd)
Problem:
Prevent an object from being accessed directly by its clients
Class Diagram
Subject Request() aClient
subject
Object Diagram
Solution:
Use an additional object, called a proxy Clients access to protected object only through proxy Proxy keeps track of status and/or location of protected object
RealSubject Request()
realSubject
... Proxy Request()
status
if (statusOK) realSubject->request(); else {};
aProxy
realSubject
aRealSubject
4
5
6
Components of a Pattern
Pattern name
identify this pattern; distinguish from other patterns define terminology
Components of a Pattern (contd)
Solution
typically natural language notation
Components of a Pattern (contd)
Implementation
critical portion of plausible code for pattern
Structure
class (and possibly object) diagram in solution
Known uses
often systems that inspired pattern
Pattern alias - also known as Real-world example Context Problem
Interaction diagram (optional) Consequences
advantages and disadvantages of pattern ways to address residual design decisions
7 8
References - See also
related patterns that may be applied in similar cases
9
Taxonomy of Patterns
Three kinds of patterns, based on purpose:
creational patterns
describe how to create objects often by delegation of responsibility from an abstract class to concrete subclasses
Principles Underlying Patterns
Rely on abstract classes to hide differences between subclasses from clients
object class vs. object type
class defines how an object is implemented type defines an objects interface (protocol)
Principles (contd)
Black-box vs. white-box reuse
black-box relies on object references, usually through instance variables white-box reuse by inheritance black-box reuse preferred for information hiding, runtime flexibility, elimination of implementation dependencies disadvantages: Run-time efficiency (high number of instances, and communication by message passing)
structural patterns
describe how to define structures and their relationships
Program to an interface, not an implementation
behavioral patterns
describe object behavior and interactions among objects
Favor composition over class inheritance
10 11 12
Principles (contd)
Delegation
powerful technique when coupled with black-box reuse Allow delegation to different instances at run-time, as long as instances respond to similar messages disadvantages:
sometimes code harder to read and understand efficiency (because of black-box reuse)
Lexi: A Simple GUI-Based Editor
Lexi is a WYSIWYG editor
supports documents with textual and graphical objects scroll bars to select portions of the document be easy to port to another platform support multiple look-and-feel interfaces
Design Issues
Representation and manipulation of document Formatting a document Adding scroll bars and borders to Lexi windows Support multiple look-and-feel standards Handle multiple windowing systems Support user operations Advanced features
spell-checking and hyphenation
Highlights several OO design issues Case study of design patterns in the design of Lexi
13
14
15
Structure of a Lexi Document
Goals:
store text and graphics in document generate visual display maintain info about location of display elements
Structure of a Lexi Document
Solution:
define abstract class Glyph for all displayed objects glyph responsibilities:
know how to draw itself knows what space it occupies knows its children and parent
Glyph Class Diagram
Glyph
Draw(window) Intersect(point) Insert(Glyph*,int)
...
Caveats:
treat different objects uniformly
e.g., text, pictures, graphics
Rectangle ... Character ...
Polygon ... Row ...
18
treat individual objects and groups of objects uniformly
e.g., characters and lines of text
16
use recursive composition for defining and handling complex objects define composition of Glyph as instances of Glyph
17
The Composite Pattern
Motivation:
support recursive composition in such a way that a client need not know the difference between a single and a composite object (as with Glyphs)
Client
Glyph Class Diagram
Composite Pattern (contd)
Consequences:
class hierarchy has both simple and composite objects simplifies clients aids extensibility
clients do not have to be modified
Component
Operation()
Children
Applicability:
when dealing with hierarchically-organized objects (e.g., columns containing rows containing words )
Leaf Composite
too general a pattern?
difficult to to restrict functionality of concrete leaf subclasses
19
20
21
Formatting Lexi Documents
Handle justification, margins, line breaking, etc. Many good algorithms exist;
different tradeoffs between quality and speed design decision: implement different algorithms, decide at run-time which algorithm to use
Compositor and Composition
Relevant design decisions:
compositor: class containing formatting algorithm pass objects to be formatted as parameters to compositor methods parameters are instances of a Glyph subclass called Composition uniform interface between formattable objects and compositor algorithms
Compositor and Composition
Relevant design decisions (contd):
each Composition instance has a reference to a compositor object when a composition needs to format itself, it sends a message to its compositor instance
Goal: maintain orthogonality between formatting and representation (glyphs) Solution
define root class that supports many algorithms each algorithm implemented in a subclass
22
23
24
Class Diagram
Name
Glyph
Insert(Glyph, int) Children
Strategy Pattern
Context
Strategy Pattern: Structure
strategy
Strategy (aka Policy)
Strategy
AlgInterface()
Applicability
Compositor
Compose () Set_Composition ()
ContextInterface()
Composition
Insert(Glyph g, int)
many related classes differ only in their behavior many different variants of an algorithm need to encapsulate algorithmic information
ConcreteStrategy
AlgInterface()
ConcreteStrategy
AlgInterface()
ConcreteStrategy
AlgInterface()
Compositor->Compose()
ArrayCompositor
Compose()
LatexCompositor
Compose()
Simple
Compose()
25 26 27
Strategy Pattern (contd)
Consequences
clear separation of algorithm definition and use
glyphs and formatting algorithms are independent alternative (many subclasses) is unappealing
proliferation of classes algorithms cannot be changed dynamically
Strategy Pattern (contd)
Consequences (continued)
clients must be aware of different strategies
when initializing objects
Adding scroll bars and borders
Where do we define classes for scrollbars and borders? Define as subclasses of Glyph
scrollbars and borders are displayable objects supports notion of transparent enclosure
clients dont need to know whether they are dealing with a component or with an enclosure
proliferation of instances at run-time
each glyph has a strategy object with formatting information if strategy is stateless, share strategy objects
elimination of conditional statements
as usual with OO programming
Inheritance increases number of classes
use composition instead (has a )
28 29 30
Monoglyph class
Glyph
Draw(Window)
Decorator Pattern
Name
Decorator (aka Wrapper)
...
Decorator Pattern: Structure
Component
Operation()
...
MonoGlyph
Draw(Window)
component
Applicability
add responsibilities to objects dynamically and transparently handle responsibilities that can be withdrawn at runtime
ConcreteComp
Operation()
component
Decorator
Operation() Component-> Operation()
Scroll Bar
Draw(Window) Draw_Scroll(Window) void MonoGlyph::Draw (Window* w){ _component->Draw(Window* w);}
Border
Draw (Window) Draw_Border (Window) MonoGlyph::Draw(w); DrawBorder(w); }
31
Concrete_Decorator_A Operation() AddedState Decorator::Op(); Added_Op();
32
Concrete_Decorator_B Operation() Added_Op()
33
Decorator Pattern (contd)
Advantages
fewer classes than with static inheritance dynamic addition/removal of decorators keeps root classes simple
Multiple look-and-feel standards
Change Lexis look-and-feel at run-time Obvious solution has clear disadvantages
use distinct class for each widget and standard let clients handle different instances for each standard
Multiple look-and-feel standards (contd)
Solution:
define abstract class GUIFactory with creation methods (deferred) for widgets concrete subclasses of GUIFactory actually define creation methods for each look-and-feel standard
MotifFactory, MacFactory, etc.
Disadvantages
proliferation of run-time instances abstract Decorator must provide common interface
Problems:
proliferation of classes cant change standard at run-time code for look-and-feel standard visible to clients
must still specialize each widget into subclasses for each look-and-feel standard
Tradeoffs:
useful when components are lightweight otherwise use Strategy
34
Code example:
Button* pb = new MotifButton; // bad Button* pb = guiFactory->createButton();// better
35 36
Class diagram for GUIFactory
GUIFactory
CreateMenu() CreateButton()
Diagram for product classes
Glyph
Abstract Factory pattern
Name
Abstract Factory or Kit
Applicability
...
MotifFactory
CreateMenu() CreateButton()
...
Button
Press()
XFactory
CreateMenu() CreateButton()
Menu
PopUp()
different families of components (products) must be used in mutually exclusive and consistent way hide existence of multiple families from clients
return new MotifMenu;
return new XMenu;
MotifButton
Press()
37
XButton
Press()
...
38 39
Structure of Abstract Factory
AbstractProductA AbstractFactory
CreateProductA() CreateProductB()
Abstract Factory (contd)
Consequences
isolate creation and handling of instances from clients changing look-and-feel standard at run-time is easy
reassign a global variable; recompute and redisplay the interface
Multiple Window Systems
Want portability to different window systems
similar to multiple problem, look-and-feel but different vendors will build widgets differently
...
ProductA1 ProductA2
...
ConcreteFactory1
CreateProductA() CreateProductB()
Solution:
define abstract class Window, with basic window functionality (e.g., draw, iconify, move, resize, etc.) define concrete subclasses for specific types of windows (e.g., dialog, application, icon, etc.) define WindowImp hierarchy to handle window implementation by a vendor
41 42
ConcreteFactory2
CreateProductA() CreateProductB()
enforces consistency among products in each family adding new family of products is difficult
have to update all factory classes
AbstractProductB
...
ProductB1 ProductB2
40
Implementation
Window DrawText() DrawRect() imp WindowImp DevDrawText() DevDrawLine()
Bridge Pattern
Name
Bridge or Handle or Body
Abstraction Operation()
Structure of Bridge Pattern
imp Implementor OperationImp()
imp->OperationImp();
...
IconWindow DrawBorder() DrawRect(); DrawText(); DrawRect();
imp->DevDrawLine; imp->DevDrawLine; imp->DevDrawLine; imp->DevDrawLine;
Applicability
handles abstract concept with different implementations implementation may be switched at run-time implementation changes should not affect clients hide a classs interface from clients
RefinedAbstraction
DialogWindow DrawCloseBox()
...
XWindowImp DevDrawText() DevDrawLine() XDrawLine () MacWindowImp DevDrawText() DevDrawLine () XDrawText()
43
Structure: use two hierarchies
logical one for clients, physical one for different implementations
44
ConcreteImplementorA OperationImp()
ConcreteImplementorB OperationImp()
45
Bridge Pattern
Consequences:
decouple interface from impl.and representation change implementation at run-time improve extensibility
logical classes and physical classes change independently hides implementation details from clients
sharing implementation objects and associated reference counts
Supporting User Commands
Support execution of Lexi commands
GUI doesnt know
who command is sent to command interface
Supporting User Commands (contd)
An improved solution
create abstract command class
command must have reversible method
Complications
different commands have different interfaces same command can be invoked in different ways Undo and Redo for some, but not all, commands (print)
create action-performing glyph subclass delegate action to command
Key ideas
pass an object, not a function pass context to the command function store command history
48
46
47
Structure of Command Pattern
Application Add(Document) Menu Add(MenuItem) Document Open() Close() ... Command Execute() MenuItem Clicked()
Command Pattern
Client
Structure of Command Pattern
Invoker
Name
Command or Action or Transaction
Applicability
parameterize objects by actions they perform specify, queue, and execute requests at different times support undo by storing context information support change log for recovery purposes support high-level operations
macros
49 50
Receiver Action()
Command Execute()
...
ConcreteCommand Execute() receiver state receiver->action();
51
command->Execute();
Command Pattern
Consequences:
decouple receiver and executor of requests
Lexi example: Different icons can be associated with the same command
Command Pattern
Implementation notes
how much should command do itself? support undo and redo functionality
operations must be reversible may need to copy command objects dont record commands that dont change state
Spell-Checking and Hyphenation
Must do texual analysis
multiple operations and implementations
commands are first class objects easy to support undo and redo
must add state information to avoid hysteresis
avoid error accumulation in undo process
Must add new functions and operations easily Must efficiently handle scattered information and varied implementations
different traversal strategies for stored information
can create composite commands
Editor macros
Should separate traversal actions from traversal
can extend commands more easily
52 53 54
Iterator Pattern
Name
Iterator or Cursor
Iterator Pattern
Key ideas
55
Structure of Iterator Pattern
AbstractList CreateIterator() Count() Append(Item) Remove(Item) Iterator First() Next() IsDone() CurrentItem()
Applicability
access aggregate objects without exposing internals support multiple traversal strategies uniform interface for traversing different objects
separate aggregate structures from traversal protocols support addition of traversal functionality small interfaces for aggregate classes, multiple simultaneous traversals abstract Iterator class defines traversal protocol concrete Iterator subclasses for each aggregate class aggregate instance creates instances of Iterator objects aggregate instance keeps reference to Iterator object
56
Client
Pattern structure
List SkipList ListIterator SkipListIterator
57
Iterator Pattern (contd)
Consequences
support different kinds of traversal strategies
just change Iterator instance
Iterator Pattern (contd)
Implementation issues
Who controls iteration?
external vs. internal iterators
external: client controls the iteration via next operation very flexible some operations are simplified - logical equality and set operations are difficult otherwise internal: Iterator applies operations to aggregate elements easy to use can be difficult to implement in some languages
58 59
Iterator Pattern (contd)
Who defines the traversal algorithm?
Iterator itself
may violate encapsulation
simplify aggregates interface
no traversal protocols
aggregate
Iterator keeps only state of iteration
supports simultaneous traversals
How roubust is the Iterator?
are updates or deletions handled? dont want to copy aggregates register Iterators with aggregate and clean-up as needed synchronization of multiple Iterators is difficult
60
Visitor pattern
Name
Visitor or double dispatching
Visitor Pattern (contd)
Structure
define two class hierarchies,
one for object structure one for operation family
Structure of Visitor Pattern
Visitor VisitElementA() VisitElementB()
...
ConcreteVisitor1 VisitElementA(ElementA) VisitElementB(ElementB) ObjectStructure ConcreteVisitor2 VisitElementA(ElementA) VisitElementB(ElementB) Element Accept(Visitor)
Applicability
r...