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