UML In Action - Design Patterns

1
 Overview
 Books
 Design Patterns – Basics
 Structural Design Patterns
 Behavioral Design Patterns
 Appendix: More on the Observer Pattern
More on the Strategy Pattern

2
Books
 Design Patterns : Elements of Reusable Object-Oriented Software
(1995)
 (The-Gang-of-Four Book)
 The-Gang-of-Four (GoF) - Gamma, Helm, Johnson , Vlissides
 Analysis Patterns - Reusable Object Models (1997)
 Martin Fowler
 The Design Patterns Smalltalk Companion (1998)
 Alpert, Brown & Woolf

3
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.

4
 Architecture vs. Design Patterns
Architecture
 High-level framework for structuring an application
 “client-server based on remote procedure calls”
 “abstraction layering”
 “distributed object-oriented system based on CORBA”
 Defines the system in terms of computational components & their
interactions
Design Patterns
 Lower level than architectures (Sometimes, called micro-architecture)
 Reusable collaborations that solve subproblems within an application
 how can I decouple subsystem X from subsystem Y?
Why Design Patterns?
 Design patterns support object-oriented reuse at a high level of abstraction
 Design patterns provide a “framework” that guides and constrains object-oriented implementation

5
4 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

6
How to Describe Design Patterns more fully
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.

 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
7
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.

8
Design Patterns Space
Purpose
Creational Structural Behavioral
Interpreter
Class Factory Method Adapter
Template
Scope
Object Abstract Factory Adapter Chain of
Builder Bridge Responsibility
Prototype Composite Command
Singleton Decorator Iterator
Façade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Visitor

9
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 can’t 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.

10
Structural Patterns
 Composite
 Adapter
 Façade
 Proxy

11
Structural Patterns - Composite
Intent
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.

12
Structural Patterns – Composite
Class Diagram

Component
Client operation()
getChild( i:int )*

Leaf Composite
operation()
operation() operation() {
add( c:Component ) for all g in children
g.operation()
remove( c:Component ) }
getChild( i:int )

13
Structural Patterns - Composite
Object Diagram

top : Composite

a : Leaf b : Leaf top : Composite c : Leaf

d : Leaf e : Leaf

14
 // "Component"
  abstract class Component
  {protected string name;

    // Constructor
    public Component(string name)
http://www.dofactory.com/Patterns/PatternComposite.aspx     {this.name = name;}

    public abstract void Add(Component c);

    public abstract void Remove(Component c);
    public abstract void Display(int depth);
using System;   }
using System.Collections;
  // "Composite"
namespace DoFactory.GangOfFour.Composite.Structural   class Composite : Component
{   {private ArrayList children = new ArrayList();

  // MainApp test application     // Constructor

    public Composite(string name) : base(name) {  }
  class MainApp
  {     public override void Add(Component component)
    static void Main()     {children.Add(component);}
    {
      // Create a tree structure     public override void Remove(Component component)
      Composite root = new Composite("root");     {children.Remove(component);}
      root.Add(new Leaf("Leaf A"));
      root.Add(new Leaf("Leaf B"));     public override void Display(int depth)
    {Console.WriteLine(new String('-', depth) + name);
      Composite comp = new Composite("Composite X");
      comp.Add(new Leaf("Leaf XA"));       // Recursively display child nodes
      comp.Add(new Leaf("Leaf XB"));       foreach (Component component in children)
      {component.Display(depth + 2);}
      root.Add(comp);     }
      root.Add(new Leaf("Leaf C"));   }
 // "Leaf"
      // Add and remove a leaf
  class Leaf : Component
      Leaf leaf = new Leaf("Leaf D");
  {// Constructor
      root.Add(leaf);
    public Leaf(string name) : base(name) {  }
      root.Remove(leaf); -root
---Leaf A     public override void Add(Component c)
      // Recursively display tree ---Leaf B     {Console.WriteLine("Cannot add to a leaf");}
      root.Display(1); ---Composite
X     public override void Remove(Component c)
      // Wait for user
-----Leaf XA     {Console.WriteLine("Cannot remove from a leaf");}
      Console.Read();
    } -----Leaf XB
---Leaf C     public override void Display(int depth) 15
  }
    {Console.WriteLine(new String('-', depth) + name);}
  }
}
Structural Patterns – Composite

Participants
Component
 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.
16
Structural Patterns – Composite
Collaborations
 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.

17
Structural Patterns - 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.

Applicability
 Reuse of an existing class is desired, but the interface does not
match the need.
 Design of a reusable class that cooperates with unrelated or
unforeseen classes, but classes don’t have compatible interfaces.

18
Structural Patterns - Adapter
Class Diagram

Adaptee
Client Target

+specialOperation()
+request()

Adapter
adaptee.specificOperation()
+request()

19
Structural Patterns - Adapter
Participants
 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.

Collaborations
 Clients call operations on an Adapter instance. In turn, the Adapter
calls Adaptee operations that carry out the request.

20
Structural Patterns - Façade
Intent
Provide a unified interface to a set of interfaces in a subsystem.
Façade 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.

21
Structural Patterns - Façade
Class Diagram

subsystem

Facade

22
Structural Patterns - Façade
Participants
 Façade
 Knows which classes are responsible for each request.
 Delegates client requests to appropriate objects.
 Subsystem classes
 Implement subsystem functionality.
 Handle work assigned by the Façade object.
 Have no knowledge of the façade.

Collaborations
 Clients communicate with the subsystem sending requests to the Façade.
 Reduces the number of classes the client deals with.
 Simplifies the subsystem.
 Clients do not have to access subsystem objects directly.
23
Structural Patterns - Proxy
Intent
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

24
Structural Patterns - Proxy
Class Diagram
<<abstract>>
Subject
Client
request()
...

RealSubject Proxy
request()
request() request() {
... ... ...
realSubject.request()
...
}

25
Structural Patterns - Proxy
Object Diagram

aClient:

aProxy : Proxy

subject : RealSubject

26
 Structural Patterns - Proxy
Participants
 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.
Collaborations
 Proxy forwards requests to RealSubject when appropriate, depending on
the kind of proxy.
27
Behavioral Patterns
 Observer
 Strategy
 Command
 State
 Visitor

28
Behavioral Patterns - Observer
Intent

 Define a one-to-many dependency between objects so that when

one object changes state, all its dependents are notified and
updated automatically.

Applicability
 An abstraction has two aspects, one dependent on the other.
 When changing one object requires changing others, and you don’t
know how many objects need changed.
 When an object needs to notify others without knowledge about who
they are.

29
Behavioral Patterns - Observer
Class Diagram

Subject
<<interface>>
* Observer
attach( observer )
detach( observer ) observers update()
notify()
for all o in observers
o.update()

observerState :=
ConcreteSubject subject.getState()
ConcreteObserver
subjectState subject
getState()
update()

30
Behavioral Patterns - Observer
Participants
 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.
Collaborations
 ConcreteSubject notifies observers when changes occur.
 ConcreteObserver may query subject regarding state change.
31
Behavioral Patterns - Observer
Sequence Diagram

subject : observer1 : observer2 :

ConcreteSubject ConcreteObserver ConcreteObserver
attach( observer1 )

attach( observer2 )

notify()
update()
getState()
update()
getState()

32
Behavioral Patterns - Strategy
Pattern

 Intent: defines a family of algorithms, encapsulate each

one, and make them interchangeable. Strategy lets the
algorithm vary independently from clients that use it.

 Motivation: when there are many algorithms for solving a

problem, hard-wiring all algorithms in client’s code may
have several problems:
 Clients get fat and harder to maintain
 Different algorithms may be appropriate at different
time
 It is difficult to add new algorithms
33
Behavioral Patterns - Strategy
Pattern

strategy
Context Strategy

ContextInterface() AlgorithmInterface()

ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC

AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()

34
Behavioral Patterns - Participants of Strategy
 Strategy: declares an interface common to all supported
algorithm. Context uses this interface to call the algorithm
defined by a ConcreteStrategy.
 ConcreteStrategy: implements the algorithm using the
Strategy interface
 Context: maintains a reference to a Strategy object and
defines an interface that let Strategy access its data

35
Behavioral Patterns - Sorting
Example
 Requirement: we want to sort a list of integers using
different sorting algorithms, e.g. quick sort, selection sort,
insertion sort, etc.
 E.g., {3, 5, 6, 2, 44, 67, 1, 344, ... }
 {1, 2, 3, 5, 6, 44, 67, 344, ... }

 One way to solve this problem is to write a function for each

sorting algorithm, e.g.
 quicksort(int[] in, int[] res)
 insertionsort(int[] in, int[] res)
 mergesort(int[] in, int[] res)
 A better way is to use the Strategy pattern 36
 Behavioral Patterns - Strategy Pattern
Main() How is stdRec implemented?
Main {…
stdRec.SetSortStr(sortStrInfo);
Main() stdRec.Sort()}

How is –sortStrategy implemented?

stdRec
-sortStrategy
SortedList SortStrategy
-list: ArrayList
Sort(list:ArrayList)
SetSortStr(sortStr:SortStrategy)
Sort()

Sort()
{sortStrategy.Sort(list)}

QuickSort InsertionSort MergeSort

Sort(list:ArrayList) Sort(list:ArrayList) Sort(list:ArrayList)

37
Behavioral Patterns - Command
Intent
Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support
undoable operations.

Applicability
 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).
38
 Behavioral Patterns - Command
Class Diagram
Client Invoker <<abstract>>
* Command
execute()

Receiver

action()

ConcreteCommand
state
execute()

receiver.action()

39
Behavioral Patterns - Command
Participants
 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.
Collaborations
 Creates a ConcreteCommand object and sets its Receiver.
 An Invoker stores the ConcreteCommand.
 Invoker calls execute() on command.
 ConcreteCommand invokes operation on its receiver.
40
 Behavioral Patterns - Command
Sequence Diagram

aClient : Client aCommand : anInvoker : aReceiver:

ConcreteCommand Invoker

create( aReceiver )

store( aCommand )

execute()

action()

41
Behavioral Patterns - State
Intent
Allow an object to alter its behavior when its internal state changes.
The object will appear to change its class.

Applicability
 An object’s 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 object’s state.
 Usually represented by constants.
 Some times, the same conditional structure is repeated.

42
Behavioral Patterns - State
Class Diagram
<<abstract>>
Context State
state
request() handle()

ConcreteStateA ConcreteStateB

handle() handle()

state.handle();

43
Behavioral Patterns - State
Participants
 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.

Collaborations
 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.
44
Behavioral Patterns - Visitor
Intent
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.

Applicability
 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.

45
 Behavioral Patterns - Visitor
Class Diagram
<<abstract>>
* Element
Client ObjectStructure
accept( v : Visitor )

<<abstract>>
Visitor

visitA( element : ConcreteElementA ) ConcreteElementA ConcreteElementB

visitB( element : ConcreteElementB )
accept( v : Visitor ) accept( v : Visitor )
operationA() operationB()

ConcreteVisitor1 ConcreteVisitor2
v.visitA( this ) v.visitB( this )
visitA( element : ConcreteElementA ) visitA( element : ConcreteElementA )
visitB( element : ConcreteElementB ) visitB( element : ConcreteElementB )

46
 Behavioral Patterns - Visitor
Participants
 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.
Collaborations
 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.
47
 Behavioral Patterns - Visitor
Sequence Diagram
aStruct : elemA : elemB : v : Visitor
ObjectStructure ConcreteElementA ConcreteElementB

accept( v )
visitConcreteElementA( elemA )

operationA()

accept( v ) visitConcreteElementB( elemB )

operationB()

48
How to Select & Use Design Patterns
How to Select (> 20 in the book, and still growing … fast?, more on Internet)
 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
How to Use
 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
49
 Appendix: More on the Observer Pattern

 Decouples a subject and its observers

 Widely used in Smalltalk to separate application objects from interface objects
 Known in the Smalltalk world as Model-View-Controller (MVC)
 Rationale:
the interface is very likely to change while the underlying business objects remain
stable
 Defines a subject (the Observable) that is observed
 Allows multiple observers to monitor state changes in the subject without
the subject having explicit knowledge about the existence of the observers

Observer

Subject Observer

Observer
50
 Appendix: More on the Observer Pattern
The Model-View-Controller (MVC)
 Developed at Xerox Parc to provide foundation classes for Smalltalk-80
 The Model, View and Controller classes have more than a 10 year history
 Fundamental Principle
 separate the underlying application MODEL (business objects) from the
INTERFACE (presentation objects)

Rationale for MVC: Design for change and reuse

Business Objects Expert Interface

(the Model in MVC)
Novice Interface
MVC and Observer Pattern
 In Smalltalk, objects may have dependents
 When an object announces “I have changed”, its dependents are notified
 It is the responsibility of the dependents to take action or ignore the notification

51
 Appendix: More on the Observer Pattern
java.util.Observable
 Observable/subject objects (the Model in Model-View) can announce
that they have changed
 Methods:
– void setChanged()
– void clearChanged()
– boolean hasChanged()
 WHAT IF Observers query a Subject periodically?
query
Subject Observer

setChanged() hasChanged()
Harry
True/false

52
 Appendix: More on the Observer Pattern
Implementing & Checking an Observable
Implementing an Observable Checking an Observable
import java.util.*;
import java.io.*; public static void main (String args [ ] ) {
Harry harry = new Harry (false);
public class Harry extends Observable {
private boolean maritalStatus = false;
harry.updateMaritalStatus (true);
public Harry (boolean isMarried) { if (harry.hasChanged() )
maritalStatus = isMarried; System.out.println ("Time to call harry");
}
}
public void updateMaritalStatus (boolean change) {
maritalStatus = change;

// set flag for anyone interested to check

this.setChanged();
}

53
 Appendix: More on the Observer Pattern
Implementing the Observer Pattern
Step 1: Observers register with Observable

addObserver (this) Observer1

Harry

addObserver (observer2) Observer2

Step 2. Observable notifies Observers

notifyObservers(Object arg)
update(Observable o, Object arg)
Harry Observer1

Observable (Harry) may also send himself a notifyObservers() msg - no params

55
 Appendix: More on the Observer Pattern
java.util.Observable
 The superclass of all ‘observable’ objects to be used in the Model
View design pattern
 Methods are provided to:
 void addObserver(anObserver)
 int countObservers()
 void deleteObserver (anObserver)
 void deleteObservers ()
 Interface
 Defines the update() method that allows an object to ‘observe’
subclasses of Observable
 Objects that implement the interface may be passed as parameters in:
 addObserver(Observer o)

56
Summary
 Design Patterns
 Creational Patterns
 Structural Patterns: Adapter, Composite, Façade, Proxy
 Behavioral Patterns: Command, Observer, State, Visitor

 Appendix: More on the Observer Pattern

 The Model-View-Controller (MVC)
 java.util.Observable

57
Points to Ponder
 List as many design patterns as you can think of in the Model-View-
Controller (MVC).
 How many design patterns can exist? In the order of tens?
hundreds? or thousands? Justify your reasoning.
 What would be the major differences between design patterns and
architectural patterns?
 What style of architecture is closest to the Observer pattern in the
manner objects interact with each other?
 Map the Observer pattern into the Java Event Model.
 What are the essential tradeoffs between
1) Observers query a Subject periodically and
2) using the Observer pattern?

58