You are on page 1of 23

Chain of Responsibility and Composite

CSCI 3132 Summer 2011


•  Consider  a  context-­‐sensi#ve  help  system  for  a  GUIDE   •  The  object  that  ul#mately  provides  the  help  isn't   known  explicitly  to  the  object  (e.g.,  a  buHon)  that   ini#ates  the  help  request.       •  So  use  a  chain  of  objects  to  decouple  the  senders   from  the  receivers.   •   The  request  gets  passed  along  the  chain  un#l  one  of   the  objects  handles  it.   •  Each  object  on  the  chain  shares  a  common  interface   for  handling  requests  and  for  accessing  its  successor   on  the  chain  

  3 .Chain  of  Responsibility  PaHern   •  Intent   – Avoid  coupling  sender  of  request  to  its  receiver  by   giving  more  than  one  object  chance  to  handle   request.    Chain  receiving  objects  and  pass  request   along  un#l  an  object  handles  it.

Example  2   4 .

 and   the  handler  isn’t  known  a  priori.Applicability   •  Use  Chain  of  responsibility  paHern  when   – more  than  one  object  may  handle  a  request.   – you  want  to  issue  a  request  to  one  of  several   objects  without  specifying  the  receiver  explicitly   – the  set  of  objects  that  can  handle  a  request   should  be  specified  dynamically   5 .

Chain  of  Responsibility  Structure   Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request 6 .

 PrintDialog)   •  Client     –  handles  requests  it  is  responsible  for   –  can  access  its  successor   –  if  the  ConcreteHandler  can  handle  the  request.  is   does  so.  otherwise  it  forwards  the  request  to  its   successor   –  ini#ates  the  request  to  a  ConcreteHandler  object  on   the  chain   7 .Chain  of  responsibility  -­‐  Par#cipants   •  Handler  (HelpHandler)   –  defines  an  interface  for  handling  requests   –  (op#onal)  implements  the  successor  link   •  ConcreteHandler  (PrintBuHon.

Chain  of  responsibility  Consequences   •  Reduced  coupling   –  The  paHern  frees  an  object  from  knowing  other  object   handles  a  request   •  Added  flexibility  in  assigning  responsibili#es  to  objects   –  changing  the  chain  in  run-­‐#me   –  use  sub-­‐classing  to  specify  handlers  sta#cally   •  Receipt  isn’t  guaranteed   8 .

private: HelpHandler* _successor.   public: HelpHandler(HelpHandler* s) : _successor(s) {} virtual void HandleHelp(). void HelpHandler::HandleHelp() { if (_successor) _successor->HandleHelp().Chain  of  responsibility  Implementa#on   •  Implemen#ng  the  successor  chain   •  Connec#ng  successors   class HelpHandler {   – define  a  new  links  (in  Handler  usually).  child-­‐parent  links). } 9 . }.  or   – use  existent  links  (for  example.

… } 10 . break.Chain  of  responsibility  Implementa#on   •  Represen#ng  requests   – The  simplest  form:  the  request  is  a  hard-­‐coded   opera#on  invoca#on   •  you  can  forward  only  the  fixed  set  of  requests   – An  alterna#ve:  use  a  single  handler  func#on   which  takes  a  request  object  as  parameter   void Handler::HandleRequest(Request* theRequest) { switch (theRequest->getKind()) { case Help: HandleHelp((HelpRequest*)theRequest).

    •  Chain  of  responsibility.     –  Command  normally  specifies  a  sender-­‐receiver  connec#on   with  a  subclass.  but  with   different  trade-­‐offs.  and  Observer.  Command.Behavioral  PaHern  Summary   •  Behavioral  paHerns  are  concerned  with  the  assignment   of  responsibili#es  between  objects.  encapsula#ng   behavior  in  an  object  and  delega#ng  requests  to  it.     –  Chain  of  responsibility  passes  a  sender  request  along  a   chain  of  poten#al  receivers.   11 .  address   how  you  can  decouple  senders  and  receivers.  or.   –  Observer  defines  a  very  decoupled  interface  that  allows  for   mul#ple  receivers  to  be  configured  at  run-­‐#me.

Structural  PaHerns   •  Concerned  with  how  classes  and  objects  are   combined  to  create  larger  structures.   •  Concerned  with  composing  objects  to   establish  new  func#onality.   12 .

13 . •  The operations are appropriate for processing and traversing trees. and another may represent an individual item. •  These hierarchies consist of both primitive and composite objects. that represent part-whole hierarchies. •  Facilitates the composition of objects into a stree structure. a hierarchy. a leaf.Composite  PaHern   •  A composite is a group of objects in which some objects contain others. one object may represent groups.

  aComposite   aLeaf   aLeaf   aComposite   aLeaf   aLeaf   aLeaf   14 .Example   •  Example:  complex  graphic  applica#on.   •  Up  and  down  delega6on:     –  A  container  may  delegate  to  all  contained  objects.   –  A  leaf/container  may  delegate  to  containing  objects.   •  Main  idea:    Containers  and  leaf  objects  appear  the  same  to  clients.  with  hierarchically  nested   objects.

Draw()   add  g  to  list  of  graphics   15 .Graphic   Draw()   Add(Graphic)   Remove(Graphic)   GetChild(int)   graphics   Line   Draw(  )   Rectangle   Draw(  )   Text   Draw(  )   Picture   Draw(  )   Add(Graphic  g)   Remove(Graphic)   GetChild(int)   forall  g  in  graphics   g.

)   –  defines  behavior  for  primi#ve  objects  in  the  composi#on   •  Composite  (Picture)   –  defines  behavior  for  components  having  children   –  stores  child  components   –  implements  child-­‐related  opera#ons  in  the  Component  interface   •  Client   –  manipulates  objects  in  the  composi#on  through  the  Component   interface   16 .Par#cipants   •  Component  (Graphic)   –  declares  interface  for  objects  in  the  composi#on   –  implements  default  behavior   –  declares  an  interface  for  accessing  and  managing  its  child  components   –  (op#onal)  declares  an  interface  for  accessing  a  component’s  parent   •  Leaf  (Rectangle.  Line.  Text  etc.

Composite  paHern  -­‐  implementa#on   •  Explicit  parent  references   –  define  the  parent  reference  in  the  Component  class   –  essen#al  to  maintain  the  invariant  that  all  children  of   a  composite  have  as  their  parent  the  composite  that   in  turn  has  them  as  children   –  easiest  way  to  ensure  -­‐  change  the  component’s   parent  only  when  it’s  being  added  or  removed  from   composite   •  Sharing  components   –  mul#ple  parents   –  ambigui#es  as  a  request  propagates  up  the  structure   17 .

I.e. 18 .Composite  PaHern  Class  Diagram   Client Component operation() Leaf operation() * Composite operation() other() Each node of the Component structure can respond to some common operation(s). the client can send the common operation to Component and the structure responds “appropriately”.

Example   MenuComponent Waitress add() remove() getChild() print()… * MenuItem print() Menu add() remove() getChild() print()… 19 .

How to implementation of print() in Menu and in MenuItem 20 .Composite  PaHern   Menu menuComponents: ArrayList add() remove() getChild() print()… Note the association from Menu to MenuComponents with an array list data type.

next().iterator(). menuComponent. System.println(".print().println("---------------------"). " + getDescription()). public void print() { System. while (iterator.out.hasNext()) { MenuComponent menuComponent = (MenuComponent)iterator.print("\n" + getName()). Iterator iterator = menuComponents.Composite  PaHern   In the Menu class we have a print() that is appropriate for an internal node.out. System.out. } } 21 .

print("(v)"). System.In the MenuItem class we have a print() that is appropriate for a leaf: public void print() { System.println(" -.print(" " + getName()).out.out.out. } Composite  PaHern   22 . " + getPrice()). } System.println(".out. if (isVegetarian()) { System." + getDescription()).

  •  New  components  can  easily  be  added  to  a  design.   23 .   •  It  enables  clients  to  to  ignore  the  specifics  of   which  leaf  or  composite  class  they  use.   •  Can  be  used  recursively.   •  Clients  interact  with  objects  through  the   component  class.Summary   •  The  Composite  PaHern  is  used  to  represent  part-­‐ whole  object  hierarchies.  so  that  Display  can  show   both  flares  and  stars.