Behavioural Patterns

Document Sample
Behavioural Patterns Powered By Docstoc
					Behavioural Patterns

       GoF pg. 221 -222
  Iterator GoF pg. 257 – 271
  Memento GoF pg. 283-291
      By: Dan Sibbernsen
                  Overview
• Behavioural
  – Concerned with algorithms and responsibilities
    among objects.
  – Also concerned with methods of communication
    between them
  – Allow you to put your “interconnected” hat on
    while taking off your “control” hat.
                     Iterator
• Intent
  – Provide a means to Iterate through a series of
    nodes in specific way(s)
• Motivation
  – To traverse lists of information without having to
    know anything too specific about the objects
  – To implement multiple algorithms to traverse
    those nodes.
Class Diagram
       Iterator:Implementation
• Who Controls the Iteration?
  – External Iterator
     • Client controls iteration
     • Client must explicitly request next() on each node
  – Internal Iterator
     • Iterator controls iteration
     • Client hands an operation to the Iterator, Iterator tells
       every child in the aggregate to perform it.
       Implementation Benefits
• External Iterator
  – More flexible than Internal. Can compare 2
    collections easily
• Internal Iterator
  – Easier to use, as they define the iteration logic for
    you. Makes portability easier.
      Who defines the traversal
            Algorithm?
• Algorithm can be held by a class outside of the
  Iterator. It could be held by the aggregate can
  hold it.
  – Called “the cursor.”
  – Allows the algorithm to access private members of
    the aggregate (and not break encapsulation)
• Algorithm is held by the iterator
  – Allows algorithms to be swapped out easily.
      How Robust is the Iterator?
• If an iterator is robust it
   – Will allow for removal of nodes in the middle of
     traversal.
   – It does this through registering the iterator with
     the aggregate. If any nodes are removed, it is
     notified.
   Additional Iterator Operations
• All come with first, next, isdone, and
  currentItem
• Previous
  – Goes to the previous node that was iterated
  – Can be helpful in certain situations
• SkipTo
  – Skips to a certain node.
  – Goes to a node matching specific criteria
Using Polymorphic Iterators in c++
• Drawbacks
  – Allocated dynamically by a factory method.
  – Client is responsible for deleting them. Can be
    error prone due to multiple levels of calls, and also
    because of exceptions
     • Proxy can be used to remedy this.
• Only use them when Polymorphism is
  required.
    Iterators may have privileged
               access
• Makes coupling tighter between Iterator and
  Aggregate
• Can be problematic if there are multiple
  iterators you want to apply
  – Solution: make private iterator-specific functions
    “protected” so that only Iterator subclasses can
    access them
        Iterators for composites
• Use an Internal iterator to keep track of the
  levels-deep it has traversed. This happens
  recursively so everything is stored on the
  stack.
               Null Iterators
• Makes traversal of Composite classes easier.
• Always returns IsDone() as true.
           Related Patterns
• Composite
• Factory Method
• Memento
         Consequences (good)
• “Supports variations in the traversal of an
  aggregate.”
• “Iterators simplify the Aggregate interface.”
• “More than one traversal can be pending on
  an aggregate.”
                   Memento
• Intent
  – “Without violating encapsulation, capture and
    externalize an object’s internal state so that the
    object can be restored to this state later.”
• Motivation
  – When we want to store off an object’s internal
    state without adding any complication to the
    object’s interface.
  – Perhaps for an undo mechanism
Class Diagram
  Undo Mechanism Complications
• Constraint-Solver problem
  – Uses multiple levels deep of objects to draw
    objects.
  – What if we want to support undo but can’t
    localize the changes to just one class?
  – Propose a Memento that gathers information
    from objects contained in a certain class
                Applicability
• Use this
  – when you want to save state on a hierarchy’s
    elements.
  – When the hierarchy’s interface would be broken if
    implementation details were exposed.
                 Participants
• Memento
  – stores the state of the Originator
• Originator
  – Creates the memento
  – “Uses the memento to restore its internal state”
• CareTaker
  – Keeps track of the Memento
  – Never uses the Memento’s Interface to the
    Originator
             Collaboration
• Pg. 286 (can’t find image)
• Caretaker requests a memento from an
  Originator.
• Caretaker passes back memento.
• Originator uses it to restore state.
         Consequences (good)
• “Preserves Encapsulation Boundaries”
• “It simplifies Originator”
• You can name your class
  “mementos_TheFreshMaker”!!!
           Consequences (bad)
• Might be expensive
• Difficulty defining interfaces to keep
  Originator encapsulated
• Hidden costs in caring for mementos
  – Caretaker could have to keep track of a lot of
    information for the memento
• You can name your class
  “mementos_TheFreshMaker” =(
              Implementation
• Language Support
  – C++ lets you call Originator a friend of Memento,
    thus giving it access to all private members of
    Memento that it needs
    Storing Incremental Changes
• If storing state happens incrementally, then
  we can just record the changes of what’s
  happened in a new memento object.
• This helps with memory difficulties.
             Related Patterns
• Command
• Iterator

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:8/31/2012
language:English
pages:26