11. Behavioral Pattern

1
11. Behavioral Pattern
2
Behavioral Patters

• Concerned with algorithms assignment of
  responsibilities
• Patterns of Communication between Objects

3
Chain of Responsibility Pattern

• 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

4
Example that would benefit from Chain Of
Responsibility Pattern

• Various types of Controls are used in an
  application. Controls handle certain events while
  they do not handle others. Each control may be
  invoked from other controls. An event not handled
  by a control must be passed on to its parent
  control.

5
Example usingChain of Responsibility Pattern
Client
Event Handler handleEvent()
Control2 handleEvent()
Control1 handleEvent()
6
When to use Chain OfResponsibility Pattern

• More than one object may handle a request, and
  the handler isnt known ahead of time.
• One of several objects may be the intended
  receiver
• Set of objects that handle request is dynamic

7
Consequences of using Chain Of Responsibility

• Reduced Coupling
• Flexibility in assigning responsibilities
• Distributes responsibilities among objects
• Receipt isnt guaranteed

8
Chain Of ResponsibilityVs. Other Patterns

• Often used with Composite
• Parent acts as Successor

9
Iterator Pattern

• Provide a way to access the elements of an
  aggregate object sequentially without exposing
  its underlying representation

10
Example that would benefit from Iterator

• Several types of collections are available
• List, Set, Queue, Vector
• We are interested in performing some operation on
  each element in a collection, without regard to
  which collection we use

11
Example usingIterator Pattern
Aggregate CreateIterator()
Iterator First() Next() IsDone() CurrentItem()
Client
ConcreateAggregate
ConcreteIterator
12
When to use Iterator Pattern

• Elements of an Aggregate needs to be accessed
  without exposing internal representation of the
  aggregate
• multiple traversals on an aggregate
• uniform traversal on different aggregates

13
Consequences of using Iterator

• Supports variations in the traversal
• Simplifies interface of Aggregates
• More than one traversal may be acting on the
  aggregate at any time

14
IteratorVs. Other Patterns

• Often applied to recursive structures such as
  Composite
• Factory method instantiate appropriate Iterator
• Memento used in conjunction with Iterator.
  Iterator stores memento internally to capture the
  state

15
Mediator Pattern

• 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 it lets you vary their
  interaction independently

16
Example that would benefit from Mediator

• An application is used to design Wheels
• The diameter of the rim is restricted by the Hub
  diameter
• The tire diameter is dependent on the rim
• The spokes length needs to be altered if hub
  diameter or rim diameter is changed

17
Example usingMediator Pattern
Hub
Rim
Mediator
Spoke
Tire
18
When to use Mediator Pattern

• Set of objects communicate in complex well
  defined way
• You want to reduce interdependency between
  objects
• Reusing object is difficult if it refers to
  several other objects
• Behavior distributed between several classes must
  be customizable without lot of sub-classing

19
Consequences of using Mediator

• Localizes behavior that may otherwise be
  distributed among several objects
• Subclass mediator to change this behavior
• Decouples Colleagues
• Replaces many-to-many interactions with
  one-to-many interaction
• Easy to maintain, extend and understand

20
Mediator Vs. Other Patterns

• Facade
• In Mediator, Colleague objects know Mediator
• In Facade subsystem classes do not see Facade
• Colleagues may communicate with Mediator using
  Observer

21
Memento Pattern

• Without violating encapsulation, capture and
  externalize an objects internal state so that
  the object can be restored to its state later

22
Example that would benefitfrom Memento

• You want to let the user modify an object
• However the user may cancel the modification
• You want to store the internal state of a complex
  object to restore it later

23
Example using Memento Pattern
Caretaker
state m-gtGetState()
return new Memento(state)
24
When to use Memento Pattern

• A snapshot of an objects state must be saved to
  restore later
• you do not want to expose the implementation
  details of the internal state of an object,
  breaking its encapsulation

25
Consequences of using Memento

• Simplifies the Originator
• Preserves encapsulation boundaries
• May be expensive
• Defining narrow and wide interfaces
• How to ensure only originator accesses mementos
  state
• Caretaker is responsible for deleting memento
• Lightweight caretakers may be burdened with large
  mementos

26
Memento Vs. Other Patterns

• Command
• May use mementos to maintain state for undo
  operations
• Iterator
• Mementos can be used for storing internal state
  of iterators

27
Observer Pattern

• Define a one-to-many dependency between objects
  so that when one object changes state, all its
  dependents are notified and updated automatically

28
Example that would benefit from Observer

• You have several views of a document
• Graph View
• TabularView
• ChartView
• The user may change the data of a document from
  any of the visible views
• You want to keep all the views synched with the
  change to the documents data

29
Example using Observer Pattern
Observers
GraphView
TabularView
ChartView
YourDocument
30
When to use Observer Pattern

• When an abstraction has two aspects one dependent
  on the other. Encapsulating these aspects in
  separate objects lets you vary and reuse them
  independently
• Change to one object requires change to others
• dont know how many objects need change
• Object is able to notify other objects without
  knowing who these objects are - dont want tight
  coupling

31
Consequences of using Observer

• Abstract the coupling between observers and
  subject
• Support for broadcast communication
• Unexpected updates
• May be expensive and untimely
• May abstract a hint on the subject change

32
Observer Vs. Other Patterns

• Mediator may be used to mediate between several
  subjects and observers

33
State Pattern

• Allow an object to alter its behavior when its
  internal state changes. The object will appear to
  change its state

34
Example that would benefit from State Pattern

• A train may run in forward or reverse mode.
• When running in forward mode the head lights on
  the front engine are on and the tail lights on
  the back engine are on.
• When running in reverse mode the reverse is true.
  
• Acceleration will move the engine forward or
  backward depending on the mode

35
Example using State Pattern
currentMode
TrainDirection
36
When to use State Pattern

• An objects behavior depends on its state and
  must change its behavior at run-time depending on
  that state
• Operations have large conditional statements that
  depend on the state. State pattern puts each
  branch of the conditional in a separate class.

37
Consequences of using State

• Localizes state-specific behavior and partitions
  behavior for different states
• Makes state transitions explicit
• State objects can be shared

38
State Vs. Other Patterns

• Flyweight pattern may be used to share state
  which may be singletons.

39
Strategy Pattern

• Define a family of algorithms, encapsulate each
  one, and make them interchangeable. Strategy lets
  the algorithm vary independently from clients
  that use it

40
Example that would benefit fromStrategy Pattern

• A property may be computed using one of several
  methods/algorithms
• Each method comes with its own features and
  trade-offs
• For instance, a method may converge towards a
  result at a faster rate but may use more memory
• Another method may not require as much memory
• Design your class such that the client may use
  any applicable method to compute property

41
Example using Strategy Pattern
methodToUse
42
When to use Strategy Pattern

• Many related classes differ only in their
  behavior. Strategy provides a way to configure
  a class with one of many behaviors
• Use different variants of an algorithm
• Algorithm uses data that clients shouldnt know
  about. Strategy avoids exposing complex
  algorithm-specific data structures
• class defines many behaviors and these appear as
  multiple conditional statements in its
  operations. Instead of many conditionals, move
  related conditional branches into their own
  strategy class.

43
Consequences of using Strategy

• Families of related algorithms
• Alternative to subclassing
• Strategies eliminate conditional statements
• Choice of implementations
• Clients must be aware of different strategies
• Communication overhead between Strategy and
  Context
• Increased number of objects

44
Strategy Vs. Other Patterns

• Often make good Flyweights