Design patterns
Upcoming SlideShare
Loading in...5
×
 

Design patterns

on

  • 348 views

 

Statistics

Views

Total Views
348
Views on SlideShare
348
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Design patterns Design patterns Presentation Transcript

  • Design  Pa*erns   addi-onal  material  
  • A  design  pa*ern  is  …   •  …  a  ba*le-­‐tested  solu-on  to  a  known  design   problem.   •  Allows  for  fast,  reliable  solu-ons.   •  Allows  quicker,  more  precise  __________.   •  Allows  a  higher  level  of  __________.  
  • An  example   •  Carpenters  making  a  drawer.   •  How  should  they  build  it?   •  Should  we  invent  a  way  to  put  the  drawer   together?   •  Perhaps  others  have  solved  the  problem   before?   •  How?  
  • Two  solu-ons   •  “We  could  cut  each  at  45  degrees  and  nail  or   glue  the  facing  pieces  together.”   •  “Maybe  we  could  make  the  joint  by  cuNng   straight  down  into  the  wood,  and  then  cut   backup  45  degrees,  and  then  going  straight   back  down,  and  then  back  up  the  other  way   45  degrees,  and  then  going  straight  back   down,  and  then  …”  
  • Miter  Joint   •  •  •  •  Easy   Quick   Cheap   Invisible  
  • Dovetail  joint   Very  complicated!   Time  consuming   Extremely  strong   Requires  no  glue  or   nails   •  Looks  beau-ful   •  •  •  • 
  • Gang  of  Four   •  Coined  “Design   Pa*erns”   •  Erich  Gamma   •  Richard  Helm   •  Ralph  Johnson   •  John  Vlissides  
  • GOF  Principles   Design  to  interfaces,  not  implementa-on.   Favor  composi-on  over  inheritance.   Find  what  varies  and  encapsulate  it.   Strive  for  loosely  coupled  designs  between   objects  that  interact.   •  Classes  should  be  open  for  extension  but   closed  for  modifica-on.   •  Depend  on  abstrac-on.    Do  not  depend  on   concrete  classes.   •  •  •  • 
  • Crea-onal  Pa*erns   •  Create  objects  at  run-me  so  that  their   characteris-cs  can  be  customized  to  the   environment.   •  Class-­‐crea-on  pa*erns     –  Use  inheritance  effec-vely  in  the  instan-a-on   process.   •  Object-­‐crea-on  pa*erns     –  Use  delega-on  effec-vely  to  get  the  job  done  
  • Factory  Method  Pa*ern   •  Define  an  interface  for  crea-ng  an  object,  but   let  subclasses  decide  which  class  to   instan-ate.     •  Factory  Method  lets  a  class  defer  instan-a-on   to  subclasses.  
  • Singleton  Pa*ern   •  Ensure  a  class  has  only  one  instance  and   provide  a  global  point  of  access  to  it.  
  • Structural  Pa*erns   •  Cover  class  and  object  composi-on.   •  Structural  class-­‐crea-on  pa*erns  use   inheritance  to  compose  interfaces.   •  Structural  object-­‐pa*erns  define  ways  to   compose  objects  to  obtain  new  func-onality.  
  • Adapter  Pa*ern   •  Convert  the  interface  of  a  class  into   another  interface  clients  expect.   •  Lets  classes  work  together  that   couldn't  otherwise  because  of   incompa-ble  interfaces.  
  • Composite  Pa*ern   •  Compose  objects  into   tree  structures  to   represent  part-­‐whole   hierarchies.     •  Composite  lets  clients   treat  individual   objects  and   composi-ons  of   objects  uniformly.  
  • Decorator  Pa*ern   •  A*ach  addi-onal   responsibili-es  to  an   object  dynamically.     •  Decorators  provide   a  flexible  alterna-ve   to  subclassing  for   extending   func-onality.    
  • Flyweight  Pa*ern   •  Use  sharing  to  support  large  numbers  of  fine-­‐ grained  objects  efficiently.    
  • Behavioral  Pa*erns   •  Cover  a  class's  objects  communica-on.   •  Concerned  with  communica-on  between   objects.  
  • Mediator  Pa*ern   •  Encapsulates  how  a  set  of  objects  interact.     •  Loose  coupling  by  keeping  objects  from  referring  to   each  other  explicitly,  and  it  lets  you  vary  their   interac-on  independently.  
  • Observer  Pa*ern   •  Define  a  one-­‐to-­‐many   dependency  between   objects  so  that  when   one  object  changes   state,  all  its   dependents  are   no-fied  and  updated   automa-cally.  
  • State  Pa*ern   •  Allow  an  object  to  alter  its  behavior  when  its   internal  state  changes.     •  The  object  will  appear  to  change  its  class.  
  • Example:  Inspector  App   •  Say  you’ve  created  a  program  that  keeps  track  of   inspec-on  results.       •  There  may  be  several  inspectors  on  the  inspec-on.   •  You  choose  a  lead  inspector  and  zero  or  more  helper   inspectors.  
  • The  Class   class LeadInspector { public LeadInspector(int personId) { // Constructor: create the lead inspector here // by reading the person info from a DB. } // More methods here }
  • How  it  is  created   public static void main() { //Make inspector 75 the lead inspector. LeadInsp insLead = new LeadInsp(75); HelpInsp helper1 = new HelpInsp(79); HelpInsp helper2 = new HelpInsp(82); //Do other inspector things below. }
  • Whoops!   •  But  what  if  we  accidentally  create  another   lead  inspector  elsewhere?   public static void main() { //Make inspector 75 the lead inspector. LeadInsp insLead = new LeadInsp(75); HelpInsp helper1 = new HelpInsp(79); HelpInsp helper2 = new HelpInsp(82); //Do other inspector things below. } Public void anotherMethod() { LeadInsp insLeader = new LeadInsp(77); }
  • Got  to  prevent  that!   •  We’ll  change  the  way  our  LeadInspector  class   provides  access  to  itself.   •  Make  the  constructor  private  so  it  can  only  be   called  internally.   •  Provide  another  method  to  provide  an   instance.   •  If  we’ve  already  created  an  instance,  provide   a  pointer  to  it  instead  of  making  a  new  one.  
  • New  instance-­‐ge*er   class LeadInspector { private static LeadInspector oneLead; private LeadInspector(int personId){ // Constructor: create the lead inspector here. } public LeadInspector getInstance(int personId){ if (oneLead == null) { oneLead = new LeadInspector(int personId); } return oneLead; } // More code here }
  • All  is  well!   •  Now,  even  if  we  (or  someone  else)  tries  to   instan-ate  another  copy  of  our  object,  we  can   provide  them  with  the  one  and  only  one   instance  of  it.   •  This  is  called  the  __________  pa*ern!  
  • Recommended  Reading   •  Head  First  Design   Pa*erns   •  By  Freeman  &   Freeman   •  O’Reilly  &   Associates   •  ISBN  0-­‐596-­‐00712-­‐4