UML

Lecture 10 Design Pattern

Books
Design Patterns : Elements of Reusable Object-Oriented
Software (1995)
The-Gang-of-Four (GoF) - Gamma, Helm, Johnson ,
Vlissides
Analysis Patterns - Reusable Object Models
Martin Fowler
The Design Patterns Smalltalk Companion
Alpert, Brown & Woolf
Design Patterns
Each pattern describes
a problem which occurs over and over again in our
environment, and then describes the core of the solution to
that problem, in such a way that you can use this solution a
million times over, without ever doing it the same way twice.
--- Christopher Alexander, 1977
This was in describing patterns in buildings and towns.
In SE, design patterns are in terms of objects and interfaces, not
walls and doors.

The manner in which a collection of interacting objects collaborate to accomplish a
specific task or provide some specific functionality.
Essential Elements of Design Patterns

Name: identifies a pattern
Problem: describes when to apply the pattern in terms of
the problem and context
Solution: describes elements that make up the design,
their relationships, responsibilities, and collaborations
Consequences: results and trade-offs of applying the
pattern

How to Describe Design Patterns more fully
A format for design patterns
Pattern Name and Classification
Intent
Also Known As
Motivation
Applicability
Structure
Participants
Collaborations
Consequences
Implementation
Sample Code
Known Uses
Related Patterns
This is critical because the information has to be conveyed to peer developers in
order for them to be able to evaluate, select and utilize patterns.
Organizing Design Patterns
By Purpose (reflects what a pattern does):
Creational Patterns
Structural Patterns
Behavioral Patterns

By Scope: specifies whether the pattern applies primarily to
classes or to
objects.
Design Patterns Space
Abstract Factory
Builder
Prototype
Singleton






Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy



Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Factory Method Adapter
Interpreter
Template
Creational Structural Behavioral



Object









Class




Scope










Purpose
Some Design Patterns
Pattern Name Role
Adapter
Convert the interface of one class into another interface
clients expect. Adapter allows classes to work together
that otherwise cant because of incompatible interfaces.
Proxy
Provide a surrogate or placeholder for another object.
Mediator
Define an object that encapsulates how a set of
objects interact. Mediator promotes loose coupling by
keeping objects from referring to each other explicitly
and let one vary its interaction independently
Observer
Define a one-to-many dependency between
objects so that when one object changes state, all
its dependents will be notified and updated automatically.
Template
Define the skeleton of an algorithm in an
operation, deferring some steps to subclasses.
Creational Patterns
Creational Patterns
Abstract Factory, Factory Method, Singleton
Concerned with object creation
Who creates what, when and how
Structural Patterns
Structural Patterns
Concerned with the composition of classes or
objects
Structural class patterns use inheritance to
compose interfaces or implementations.
Structural object patterns describe ways to
compose objects to realize new functionality.
Behavioral Patterns
Behavioral Patterns
Characterize the ways in which classes or
objects interact and distribute responsibility
Behavioral patterns are concerned with
algorithms and the assignment of
responsibilities between objects.
Behavioral patterns also describe patterns of
communication between objects and classes.
Sample - Adapter Pattern
Structural Pattern
Adapter
Intermediary acts like a translator between the
client and the server.
Client
Adapter
Server
Example
Requirements Change
Add Triangle object
Example
Suppose XTriangle class has already existed
Xdraw
Xgetarea
Solutions:
Create class Triangle derives from Shape
Triangle contains Xtriangle (composition
relationship)
Triangle passes requests made to the Triangle
object on through to the XTriangle object
Example
Class Triangle extends Shape{

private XTriangle tgl

public Triangle(){
tgl=new XTriangle();
}
void public draw(){
tgl.Xdraw();
}
}
Adapter
Client
Adapter
+request()
Adaptee
+specificOperation()
Target
+request()
adaptee.specificOperation()
Class Diagram
Canvas Shape
Triangle
XTriangle
Xtriangle.Xdraw()
Adapter
Intent:
Match an existing object beyond your control to a particular interface.
Problem:
A system has the right data and behavior but the wrong interface. Typical used when
you have to make something a derivative of an abstract class we are defining or already
have.
Solution:
The adapter provides a wrapper with the desired interface.
Participants and Collaborators:
The Adapter adapts the interface of an Adaptee to match that of Adapters Target(the
class it derives from). This allows the Client to use the Adaptee as if it were a type of
Target.
Consequences:
The Adapter pattern allows for preexisting objects to fit into new class structures
without being limited by their interfaces.
Implementation:
Contain the existing class in another class. Have the containing class match the required
interface and call the methods of the contained class.



Adapter
Target defines the domain-specific interface that the client uses.
Client collaborates with objects conforming to the Target
interface.
Adaptee defines an existing interface that needs adapting.
Adapter adapts the interface of Adaptee to the Target interface.
Participants
Clients call operations on an Adapter instance. In turn, the
Adapter calls Adaptee operations that carry out the request.
Collaborations
Name: 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: Sometimes a toolkit class that's designed
for reuse isn't reusable only because its interface
doesn't match the domain-specific interface an
application requires.

Adapter Summery
Adapter Summery
Applicability use the Adapter when:
You want to use an existing class, and its interface does not
match the one you need.
You want to create a reusable class that cooperates with
unrelated or unforeseen classes, that is, classes that
dont necessarily have compatible interfaces.
(object adapter only) you need to use several existing
subclasses, but its impractical to adapt their interface by
subclassing every one. An object adapter can adapt the
interface of its parent class.
Task
Creational Pattern
Singleton
Abstract Factory
Factory Method
Structural Pattern
Bridge
Facade
Decorator
Behavioral Pattern
Strategy
Observer
Template Method
..

MORE FYI
Singleton Pattern
Creational Pattern
Singleton Pattern
The Singleton pattern ensures that a class has
only one instance and provides a global point of
access to it.
Examples:
There can be many printers in a system but there
should only be one printer spooler.
There should be only one instance of a
WindowManager.
There should be only one instance of a filesystem.

Singleton Pattern
How do we ensure that a class has only one instance
and that the instance is easily accessible?
A global variable makes an object accessible, but
does not keep you from instantiating multiple objects.
A better solution is to make the class itself
responsible for keeping track of its sole instance. The
class ensures that no other instance can be created
(by intercepting requests to create new objects) and
it provides a way to access the instance.
Singleton Pattern
Use the Singleton pattern when
There must be exactly one instance of a
class, and it must be accessible to clients
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.
Singleton Class Diagram
Singleton Particpants
Singleton
Defines an Instance operation that lets clients
access its unique instance. Instance is a class
operation (static method)
Responsible for creating its own unique instance
Client
Accesses a Singleton instance solely through the
Singletons Instance() method.
Singleton Consequences
Controlled access to sole instance
Because the Singleton class encapsulates its sole
instance, it can have strict control over how
and when clients access it.
Reduced name space
The Singleton pattern is an improvement over
global variables. It avoids polluting the name
space with global variables that store sole
instances.
Singleton Consequences
Permits refinement of operations and
representations
The Singleton class may be subclassed and it is easy
to configure an application with an instance of this
extended class at run-time.
More flexible than class operations
An alternative is to use static member functions.
However it is difficult to change the design to allow
more than one instance of a class and static
member functions are not polymorphic, so
subclasses can not override them.
Singleton Implementation
Ensuring a unique instance
The Singleton pattern makes the sole instance a
normal instance of a class, but that class is
written so that only one instance can ever be
created. A common way to do this is to hide
the operation that creates the instance behind
a static class operation that guarantees that
only one instance is created.
Singleton Sample Code
class Singleton {
private static Singleton instance;
static Singleton getInstance() {
if (instance == null) // if not created yet
instance = new Singleton(); // create once
return instance;
}
// clients access the Singleton exclusively through
// the getInstance() member function
protected Singleton() {}
// the constructor is protected, such that a client
// can never instantiate a Singleton
}
lazy instantiation
Singleton Sample Code
class Singleton {
private static Singleton instance;
static Singleton Instance(SingletonType t) {
if (instance == null) {
if (t==SINGLETON)
instance = new Singleton();
if (t==MYSINGLETON)
instance = new MySingleton();
}
return instance;
}
protected Singleton() {}
}
class MySingleton extends Singleton
{ }
Problems with the above implementation
protected constructors can be called by
subclasses and by other classes in the same
package
two solutions:
make the ClassicSingleton constructor private so that only
ClassicSingleton() methods call it; however, that means
ClassicSingleton cannot be subclassed
put singleton class in an explicit package, so classes in other packages
(including the default package) cannot instantiate singleton instances
Factory Method Pattern
Factory Method
Factory Method defines an interface for creating an object,
but let subclasses decide which class to instantiate.
Factory Method lets a class defer instantiation to
subclasses.
Factory Method
Frameworks use abstract classes to define and maintain relationships
between objects.
A Framework is often responsible for creating these objects as well.
Consider a framework for applications that can present multiple
documents to the user.
The framework contains abstractions for Application and Document.
Both classes are abstract and clients have to subclass them to realize
their application-specific implementations.
To create a drawing application for example, we define sub-classes
DrawingApplication and DrawingDocument.
Factory Method
The particular Document sub-class is application specific,
the Application class can not predict the sub-class of a
Document to instantiate.
The Application only knows when a new document
should be created, not what kind of Document to create.
The problem, the framework must instantiate classes, but
it only knows about abstract classes, which it cannot
instantiate.
The Factory Method encapsulates the knowledge of
which Document sub-class to create and moves this
knowledge out of the framework.
Factory Method Class Diagram
Document
+Open()
+Close()
+Save()
+Revert()
Application
+CreateDocument()
+NewDocument()
+OpenDocument()
MyDocument MyApplication
+CreateDocument()
docs
return new MyDocument();
Document doc = CreateDocument();
docs.Add(doc);
doc.Open();
Factory Method Applicability
Use the Factory Method pattern when
A class cannot anticipate the class of
objects it must create.
A class wants its sub-classes to specify the
objects it creates.
Classes delegate responsibility to one of
several helper sub-classes, and you want to
localize the knowledge of which helper sub-
class is the delegate.
Factory Method Class Diagram
Product Creator
+FactoryMethod()
+Operation()
ConcreteProduct ConcreteCreator
+FactoryMethod()
return new ConcreteProduct();
...
product = FactoryMethod();
...
Factory Method Participants
Product
Defines the interface of objects the factory
method creates
ConcreteProduct
Implements the Product interface
Factory Method Participants
Creator
Declares the factory method, which returns an
object of type Product. Creator may also define a
default implementation of the factory method that
returns a default ConcreteProduct
May call the factory method to create a Product
object
ConcreteCreator
Overrides the factory method to return an instance
of a ConcreteProduct

Factory Method Consequences
Factory eliminates the need to bind
application-specific classes into your code.
The code only deals with the Product
interface, therefore it can work with any
user-defined Concrete-Product classes.
A potential disadvantage is that clients
might have to sub-class the Creator class
just to create a particular ConcreteProduct
object.
Factory Method Consequences
Provides hooks for subclasses: Creating
objects inside a class with a factory method
is always more flexible than creating an
object directly. Factory methods give sub-
classes a hook for providing an extended
version of an object.
Connects parallel class hierarchies:

Factory Method Implementation
Two main variations of Factory Method
Creator is an abstract class and does not provide
an implementation for factory method. Requires
sub-classes to define an implementation, but you
do not have to instantiate unforeseeable classes.
Creator is a concrete class and provides a default
implementation for factory method. The Creator
uses the factory method primarily for flexibility,
allowing sub-classes to change the class of objects
their parent class instantiates if necessary.
Factory Method Implementation
Parameterized factory methods
The factory method can create multiple kinds of
products. The factory method takes a parameter
that identifies the kind of object to create. All
objects the factory method creates share the
Product interface.
class Creator {
Product FactoryMethod(ProductID id) {
if (id==MINE) return new MyProduct();
if(id==YOURS) return new YourProduct();
}
}
Factory Method Implementation
Using templates to avoid subclassing:
In C++ one can use a template sub-class of Creator that is
parameterized by the Product class.
template <class TheProduct > class Creator
{
public:
virtual Product* CreateProduct() {
return new TheProduct;
};
};
Class MyProduct : public Product { };
Creator<MyProduct> my Creator;
Abstract Factory Pattern
Abstract Factory
Abstract factory provides an interface for
creating families of related or dependent
objects without specifying their concrete
classes.
Abstract Factory
Consider a user-interface toolkit that
supports multiple look-and-feel standards
such as Motif and Presentation Manager.
Different toolkits define different
appearances and behaviors for user
interface widgets like scroll-bars, windows
and buttons.
To be portable across different toolkits an
application should not hard-code its
widgets for a particular toolkit.
Abstract Factory
Abstract Factory solves this problem by defining an
abstract WidgetFactory class that declares an interface
for creating each basic kind of widget.
There is also an abstract class for each kind of widget,
and concrete sub-classes implement widgets for
specific toolkits.
Widget Factory (Factory Method) provides an interface
that returns a new widget object for each abstract
widget class.
Clients use Widget Factory to obtain widget instances
but are unaware of the concrete classes they are using.
Abstract Factory
Use the abstract factory pattern when
A system should be independent of how its products are
created, composed and represented.
A system should be configured with multiple families of
products.
A family of related product objects is designed to be used
together, and you need to enforce this constraint.
You want to provide a class library of products, and you
want to reveal just their interfaces not their
implementations.
Abstract Factory Class Diagram
AbstractFactory
+CreateProductA()
+CreateProductB()
ConcreteFactory1
+CreateProductA()
+CreateProductB()
ConcreteFactory2
+CreateProductA()
+CreateProductB()
AbstractProductA
ProductA2
ProductA1
AbstractProductB
ProductB2
ProductB1
Client
Abstract Factory Participants
AbstractFactory (WidgetFactory)
Declares an interface for operations that create
abstract product objects.
ConcreteFactory (MotifWidgetFactory,
PMWidgetFactory)
Implements the operations to create concrete
products.
Abstract Factory Participants
AbstractProduct (Window, ScrollBar)
Declares an interface for a type of product.
ConcreteProduct (MotifWindow, MotifScrollBar)
Defines a product object to be created by the corresponding
concrete factory.
Implements the AbstractProduct interface
Client
Uses only the interfaces declared by AbstractFactory and
AbstractProduct
Abstract Factory Collaborations
Normally a single instance of a
ConcreteFactory class is created at run-time.
ConcreteFactory is implemented as a
Singleton.
AbstractFactory defers the creation of
product objects to its ConcreteFactory sub-
class, using the Factory Method pattern.
Abstract Factory Consequences
Abstract Factory isolates classes: It helps you to control the classes of
objects that an application creates. It isolates clients from
implementation classes as the client manipulates instances solely
through their abstract interfaces.
It makes exchanging product families easy: The class of a concrete
factory appears only once in an application that is where it is
instantiated. This makes it easy to change the concrete factory an
application uses. It can use different product configurations simply by
changing the ConcreteFactory.
Abstract Factory Consequences
It promotes consistency among products: When product objects in a family
are designed to work together, it is important that the application use
objects from only one family at a time.
Supporting new kinds of products is difficult: Extending abstract factories to
produce new kinds of Products is difficult, because the AbstractFactory
interface fixes the set of products that can be created. Supporting new
products requires extending the factory interface, which involves changing
the AbstractFactory class and all its ConcreteFactory sub-classes.
Abstract Factory Implementation
Factories as Singletons: An application typically needs only one
instance of a ConcreteFactory per product family.
Creating the Products: AbstractFactory only declares an interface for
creating products. It is up to the ConcreteProduct sub-classes to
actually create them. The most common way to do this is do define a
Factory Method for each Product.
AbstractFactory vs. FactoryMethod
AbstractFactory Creator
ConcreteFactory ConcreteCreator
AbstractProduct Product
Product ConcreteProduct
Structural Patterns
Adapter
Composite
Faade
Proxy
Composite Pattern
Structural Patterns - Composite
Compose objects into tree structures to represent part-whole
hierarchies. Composite lets clients treat individual objects
and compositions of objects uniformly.

Composite: Applicability
Represents part-whole hierarchies of objects.
Clients ignore the difference between compositions of objects
and individual objects.
Clients treat all objects in the composite structure uniformly.
Intent
Structural Patterns Composite
Class Diagram
Client
Component
operation()
getChild( i:int )
Leaf
operation()
Composite
operation()
add( c:Component )
remove( c:Component )
getChild( i:int )
operation()
{
for all g in children
g.operation()
}
*
Structural Patterns - Composite
Object Diagram
top : Composite
top : Composite a : Leaf b : Leaf c : Leaf
d : Leaf e : Leaf
Structural Patterns Composite
Declares the interface for objects in the composition.
Implements default behavior for the interface common to all classes, as
appropriate.
Declares an interface for accessing and managing its child components.
Optionally defines an interface for accessing a components parent.
Leaf
Represents leaf objects in the composition.
Defines behavior for primitive objects in the composition.
Composite
Defines behavior for components having children.
Stores child components.
Implements child-related operations.
Client
Manipulates objects in the composition through the Component interface.
Component
Participants
Structural Patterns Composite
Clients use the Component class interface to interact with
objects in the composite structure.
If the recipient is a Leaf, then the request is handled directly.
If the recipient is a Composite, then it usually forwards
requests to its child components, possibly performing additional
operations before and/or after forwarding.
Collaborations
Structural Patterns - Faade
Provide a unified interface to a set of interfaces in a subsystem.
Faade defines a higher-level interface that makes the
subsystem easier to use.
Applicability
Provides a simple interface to a complex subsystem.
Decouples the details of a subsystem from clients and other
subsystems.
Provides a layered approach to subsystems.
Intent
Faade Pattern
Structural Patterns - Faade
Class Diagram
subsystem
Facade
Structural Patterns - Faade
Faade
Knows which classes are responsible for each request.
Delegates client requests to appropriate objects.
Subsystem classes
Implement subsystem functionality.
Handle work assigned by the Faade object.
Have no knowledge of the faade.

Participants
Clients communicate with the subsystem sending requests to the
Faade.
Reduces the number of classes the client deals with.
Simplifies the subsystem.
Clients do not have to access subsystem objects directly.
Collaborations
Proxy Pattern
Structural Patterns - Proxy
Provide a surrogate or placeholder for another object to control
access to it.
Applicability
Remote proxy provides a local representative for an object in
a different address space.
Virtual proxy creates expensive objects on demand.
Protection proxy controls access to the original object.
Smart reference replacement for a bare pointer
Reference counting
Loading persistent object on access
Transactional locking
Intent
Structural Patterns - Proxy
Class Diagram
Client
<<abstract>>
Subject
request()
...
RealSubject
request()
...
Proxy
request()
...
request()
{
...
realSubject.request()
...
}
Structural Patterns - Proxy
Object Diagram
aClient:
aProxy : Proxy
subject : RealSubject
Structural Patterns - Proxy
Subject: Defines the common interface for RealSubject and Proxy.
Proxy:
Maintains reference to real subject
Can be substituted for a real subject
Controls access to real subject
May be responsible for creating and deleting the real subject
Special responsibilities
Marshaling for remote communication
Caching data
Access validation

RealSubject: Defines the real object that the proxy represents.
Client: Accesses the RealSubject through the intervention of the Proxy.
Participants
Proxy forwards requests to RealSubject when appropriate, depending
on the kind of proxy.
Collaborations
Behavioral Patterns
Command
Observer
State
Visitor
Command Pattern
Behavioral Patterns - Command
Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support
undoable operations.

Intent
Parameterize objects by an action
In place of callbacks
Specify, queue, and execute requests at different times
Supports undo when Command maintains state information
necessary for reversing command.
Added support for logging Command behavior.
Support high-level operations built on primitive operations
(transactions).
Applicability
Behavioral Patterns - Command
Class Diagram
*
Client Invoker
action()
Receiver
execute()
<<abstract>>
Command
execute()
state
ConcreteCommand
receiver.action()
Behavioral Patterns - Command
Command: Declares an interface for executing an operation.
ConcreteCommand
Defines a binding between a Receiver object and an action.
Implements execute() by invoking a corresponding operation on
Receiver.
Client (Application): Creates a Command object and sets its Receiver.
Invoker: Asks the Command to carry out a request.
Receiver: Knows how to perform the operation associated with a
request. Can be any class.
Participants
Creates a ConcreteCommand object and sets its Receiver.
An Invoker stores the ConcreteCommand.
Invoker calls execute() on command.
ConcreteCommand invokes operation on its receiver.
Collaborations
Behavioral Patterns - Command
aClient : Client aReceiver:
anInvoker :
Invoker
aCommand :
ConcreteCommand
create( aReceiver )
store( aCommand )
action()
execute()
Sequence Diagram
Behavioral Patterns - Observer
Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified
and updated automatically.

Intent
An abstraction has two aspects, one dependent on the other.
When changing one object requires changing others, and you
dont know how many objects need changed.
When an object needs to notify others without knowledge about
who they are.
Applicability
Observer Pattern
Behavioral Patterns - Observer
Class Diagram
subject
observers
*
update()
ConcreteObserver
attach( observer )
detach( observer )
notify()
Subject
for all o in observers
o.update()
getState()
subjectState
ConcreteSubject
update()
<<interface>>
Observer
observerState :=
subject.getState()
Behavioral Patterns - Observer
Subject
Knows its observers, but not their real identity.
Provides an interface for attaching/detaching observers.
Observer
Defines an updating interface for objects that should be identified of
changes.
ConcreteSubject
Stores state of interest to ConcreteObserver objects.
Sends update notice to observers upon state change.
ConcreteObserver
Maintains reference to ConcreteSubject (sometimes).
Maintains state that must be consistent with ConcreteSubject.
Implements the Observer interface.
Participants
ConcreteSubject notifies observers when changes occur.
ConcreteObserver may query subject regarding state change.
Collaborations
Behavioral Patterns - Observer
Sequence Diagram
subject :
ConcreteSubject
observer1 :
ConcreteObserver
observer2 :
ConcreteObserver
attach( observer1 )
attach( observer2 )
update()
getState()
update()
getState()
notify()
Behavioral Patterns - State
Allow an object to alter its behavior when its internal state changes.
The object will appear to change its class.

Intent
An objects behavior depends on its state, and it must change its
behavior at run-time depending on its state.
Operations have large, multipart conditional statements that
depend on the objects state.
Usually represented by constants.
Some times, the same conditional structure is repeated.
Applicability
State Pattern
Behavioral Patterns - State
Class Diagram
state
request()
Context
state.handle();
handle()
<<abstract>>
State
handle()
ConcreteStateA
handle()
ConcreteStateB
Behavioral Patterns - State
Context
Defines interface of interest to clients.
Maintains an association with a subclass of State, that defines the current state.
State
Defines an interface for encapsulating the behavior with respect to state.
ConcreteStatex
Each subclass implements a behavior associated with a particular state of the
Context.
Participants
Context delegates state-specific behavior to the current concrete State object.
The state object may need access to Context information; so the context is
usually passed as a parameter.
Clients do not deal with State object directly.
Either Context or a concrete State subclass can decide which state succeeds
another.
Collaborations
Visitor Pattern
Behavioral Patterns - Visitor
Represent an operation to be performed on the elements of an object
structure. Visitor lets you define a new operation without changing
the classes of the elements on which it operates.
Intent
An object structure contains many disparate classes, and
operations need to be performed based on concrete classes.
Many distinct operations need to be performed on an object
structure.
An object structure rarely changes, but new operations need to
be defined over the structure.
Applicability
Behavioral Patterns - Visitor
Class Diagram
*
Client
visitA( element : ConcreteElementA )
visitB( element : ConcreteElementB )
<<abstract>>
Visitor
visitA( element : ConcreteElementA )
visitB( element : ConcreteElementB )
ConcreteVisitor1
visitA( element : ConcreteElementA )
visitB( element : ConcreteElementB )
ConcreteVisitor2
ObjectStructure
accept( v : Visitor )
<<abstract>>
Element
accept( v : Visitor )
operationA()
ConcreteElementA
accept( v : Visitor )
operationB()
ConcreteElementB
v.visitA( this ) v.visitB( this )
Behavioral Patterns - Visitor
Visitor declares a visit operation for each class within the object structure
aggregation.
ConcreteVisitor implements each operation declared by Visitor. Provides
algorithm context.
Element defines an accept operation taking a Visitor as an argument.
ConcreteElementX implements an accept operation taking a Visitor as an
argument.
ObjectStructure
Enumerates its elements; potentially disparate classes.
May provide a high level interface for visitor to visit its elements.
Potentially a composite or just a general collection.
Participants
A client creates an instance of a concrete Visitor subclass.
Client requests the ObjectStructure to allow the visitor to visit each.
When visited, Element invokes the appropriate operation on Visitor;
overloading to know the element type.
Collaborations
Behavioral Patterns - Visitor
Sequence Diagram
aStruct :
ObjectStructure
v : Visitor
elemB :
ConcreteElementB
elemA :
ConcreteElementA
accept( v )
accept( v )
visitConcreteElementB( elemB )
operationB()
visitConcreteElementA( elemA )
operationA()
How to Select & Use Design Patterns
Scan Intent Sections
Study How Patterns Interrelate
Study Patterns of Like Purpose
Examine a Cause of Redesign
Consider What Should Be Variable in Your Design
Read the pattern once through for an overview: appears trivial, but not
Go back and study the structure, participants, and collaborations
sections
Look at Sample Code: concrete example of pattern in code
Choose names for pattern participants
Define the classes
Define application specific names for operations in the pattern
Implement the operations to carry out the responsibilities and
collaborations in the pattern

How to Use
How to Select (> 20 in the book, and still growing fast?, more on Internet)
Mediator Pattern
Mediator Pattern
Different dialog boxes will have different
dependencies between widgets, which
makes it impossible to simply reuse a
standard set of widget classes.
Instead widget classes have to be
customized to reflect dialog-specific
dependencies, which would require a large
number of separate subclasses for different
types of dialogs.

Coupling between Classes
Special
Button
Special
Entry Field
Special
ListBox
list
button field
field
button
list
Mediator Pattern
Encapsulating the collective behavior in a separate Mediator
object avoids these problems.
A Mediator object is responsible for controlling and
coordinating the interactions of a group of objects.
The Mediator serves as an intermediary that keeps objects in
the group from refering to each other explicitly.
The objects only know the Mediator thereby reducing the
number of interactions.
Mediator Pattern
FormDialog
Director
Client
director
Button
Entry
Field
ListBox
director director
director
button field
list
Mediator Pattern
The FormDialogDirector is the mediator
between the widgets in the dialog box.
The FormDialogDirector knows the widgets
in a dialog and coordinates their interaction.
The FormDialogDirector acts as a hub of
communications for widgets.
Mediator Sequence Diagram
aListBox
Widget
Changed()
SetText()
anEntry
Field
ShowDialog()
aClient
aFormDialog
Director
Get
Selection()
aButton
EnableButton()
Mediator Structure
DialogDirector
ShowDialog()
CreateWidgets()
WidgetChanged(w)
Widget
Changed()
director
FormDialogDirector
CreateWidgets()
WidgetChanged(w)

ListBox
GetSelection()

field
EntryField
SetText()

list
Director->
WidgetChanged(this)
Mediator Pattern
DialogDirector is an abstract class that defines the overall
behavior of a dialog.
Clients call the ShowDialog operation to display the dialog on
the screen.
CreateWidgets is an abstract operation for creating the widgets
of a dialog.
WidgetChanged is another abstract operation, widgets call it to
inform their director that they have changed.
DialogDirector subclasses override CreateWidgets to create the
proper widgets, and they override WidgetChanged to handle
the changes.

Mediator Sample Code
class DialogDirector
{
public:
virtual void ShowDialog();
virtual void WidgetChanged(Widget *)=0;
protected:
DialogDirector();
virtual void CreateWidgets() = 0;
};
Mediator Sample Code
class Widget
{
public:
Widget(DialogDirector*);
virtual void Changed();
virtual void HandleMouseEvent(MouseEvent& event);
private:
DialogDirector* director_;
};

void Widget::Changed() {
director->WidgetChanged(this); }
Mediator Sample Code
class ListBox : public Widget
{
public:
ListBox(DialogDirector*);
virtual const string GetSelection();
virtual void HighLight(string selection);
virtual void SetList(list<string> newlistItems);
virtual void HandleMouseEvent(MouseEvent& event);
private:
list<string> listItems;
};

Mediator Sample Code
class EntryField : public Widget
{
public:
EntryField(DialogDirector*);
virtual const string GetText();
virtual void SetText(const string newtext);
virtual void HandleMouseEvent(MouseEvent& event);
private:
string text;
};

Mediator Sample Code
class Button : public Widget
{
public:
Button(DialogDirector*);
virtual void SetText(const string newtext);
virtual void HandleMouseEvent(MouseEvent& event);
virtual void Activate();
virtual void DeActivate();
private:
bool active;
};

Mediator Sample Code
class FormDialogDirector : public DialogDirector
{
public:
FormDialogDirector()
virtual void WidgetChanged(Widget *);
protected:
virtual void CreateWidgets();
private:
ListBox* list;
EntryField* field;
Button* ok_button;
Button* cancel_button;
};
Mediator Sample Code
void FormDialogDirector::CreateWidgets()
{
list = new ListBox(this);
field = new EntryField(this);
ok_button = new Button(this);
cancel_button = new Button(this);
ok_button->DeActivate();
ok_button->SetText(OK);
cancel_button->Activate();
cancel_button->SetText(Cancel);
// fill the ListBox with the available names
list->SetList(...);
}
Mediator Sample Code
void FormDialogDirector::WidgetChanged
(Widget* ChangedWidget) {
if (ChangedWidget==list)
field->SetText(list->GetSelection());
if (ChangedWidget==field) {
list->Highlight(field->GetText());
if (field->GetText() != )
ok_button->Activate();
else
ok_button->DeActivate(); }
}
if (ChangedWidget==ok_button)
...
}
Mediator Applicability
Use the Mediator pattern when
A set of objects communicate in well-defined complex ways.
The resulting interdependencies are unstructured and
difficult to understand.
Reusing an object is difficult because it refers to and
communicates with many other objects.
A behavior that is distributed between several classes should
be customizable without a lot of subclassing.

Mediator Pattern Structure
Mediator

Colleague

mediator
Concrete
Mediator
Concrete
ColleagueA
Concrete
ColleagueB
Mediator Pattern Participants
Mediator
defines an interface for communicating with
Colleague objects.
ConcreteMediator
Implements cooperative behavior by coordinating
Colleague objects.
Colleague classes
Each colleague knows its mediator
Each colleague communicates with its Mediator
whenever it would have otherwise communicated
with another colleague
Mediator Pattern Collaborations
Colleagues send and receive requests from
a Mediator object.
The Mediator implements the cooperative
behavior by routing requests between the
appropriate colleagues
Mediator Pattern Consequences
The Mediator pattern limits subclassing. A mediator localizes
behavior that otherwise would be distributed among several
objects. Changing this behavior requires subclassing Mediator
only, Colleague classes can be reused.
The Mediator pattern decouples colleagues. A mediator
promotes loose coupling between colleagues. You can vary
and reuse Colleague and Mediator classes independently.
Mediator Pattern Consequences
The Mediator pattern simplifies object protocols. A
mediator replaces many-to-many interactions with one-to-
many interactions between the mediator and its colleagues.
One-to-many relationships are easier to understand,
maintain and extend.
The Mediator pattern abstracts how objects cooperate.
Making mediation an independent concept and
encapsulating it in an object lets you focus on how objects
interact apart from their individual behavior. That can help
clarify how objects interact in a system.
Mediator Pattern Consequences
The mediator pattern centralizes control.
The Mediator pattern trades complexity of
interaction for complexity in the mediator.
Because a mediator encapsulates protocols,
it can become more complex than an
individual colleague. This can make the
mediator itself a monolith that is hard to
maintain.
Mediator Pattern Implement.
Omitting the abstract Mediator class.
There is no need to define an abstract
Mediator class when colleagues work with
only one mediator. The abstract coupling
that the Mediator class provides lets
colleagues work with different subclasses
and vice versa.

Mediator Pattern Implement.
Colleague-Mediator communication.
Colleagues have to communicate with their
mediator when an event of interest occurs.
One approach is to implement the
Mediator as an Observer. Colleague classes
act as Subjects, sending notifications to the
mediator whenever they change state. The
mediator responds by propagating the
effects of the change to the other
colleagues.
Mediator Pattern Game
Game
Manager
Player
manager
Token
Board
Dice
manager manager
manager
token board
dice
Chain of Responsibility (CoR)
Pattern
Behavioral Patterns Chain of
Responsibility (CoR)
Avoid coupling the sender of a request to its receiver by giving
more than one object a chance to handle the request. Chain the
receiving objects and pass the request along the chain until an
object handles it.
Intent
You want to decouple a request's sender and receiver
Multiple objects, determined at runtime, are candidates to handle a
request
You don't want to specify handlers explicitly in your code
Applicability
Behavioral Patterns - Command
Class Diagram
Behavioral Patterns - Command
Handler:
Defines the interface for handling the requests
May implement the successor link
ConcreteHandler
Handles requests it is responsible for
Can access its successor
Handles the request if it can do so, otherwise it forwards the request to
its successor
Client: initiates the request to a ConcreteHandler object on the chain.

Participants
If you use the CoR pattern, remember:
Only one object in the chain handles a request
Some requests might not get handled
Those restrictions, of course, are for a classic CoR implementation. In
practice, those rules are bent; for example, servlet filters are a CoR
implementation that allows multiple filters to process an HTTP request.
Behavioral Patterns - Command
aClient : Client aReceiver:
anInvoker :
Invoker
aCommand :
ConcreteCommand
create( aReceiver )
store( aCommand )
action()
execute()
Sequence Diagram
Expanding Our Horizons
OO Design
Fundamental Concepts
Objects
Traditional way: bundle of data and method
New way: things with responsibility
Encapsulation
Traditional way: hiding data
New way: the ability to hiding anything
Abstract classes/inheritance
Traditional way: for specialization and reuse
New way: as method of classifying objects
Find what is varying and Encapsulate it