You are on page 1of 23

Introduc)on  to  UML   Adapter  Pa3ern  and  Façade   Pa3ern  Revisit  

CSCI 3132 Summer 2011

Quick  Intro  to  UML  (Unified  Modeling  Language)    
•  The  Unified  Modeling  Language  is  a  visual  language  used  to  create   models  of  programs.  

UML  has  several  different  diagrams:  each  show  the  rela)onship   among  different  sets  of  en))es,  depending  upon  the  purpose  of  the   diagram.   Use  Case  (Analysis  Phase)     involve  en))es  interac)ng  with  the  system   Interac)on  Diagrams  (Looking  at  Objects  Interac)ons)     Shows  how  specific  objects  interact  with  each  other   Class  Diagrams  (Design  Phase)     detail  the  rela)onships  between  classes   State  Diagrams  (Looking  at  Objects  Behaviors)     Detail  the  different  states  an  object  may  be  in  as  well  as  the   transi)ons  between  states   2 • 

  When  one  class  is  a  “kind  of”  another  class.Class  Diagram   Describes  classes  and  shows  the  rela)onships  between  them.  the  is-­‐a  rela)onship   When  there  are  associa)ons  between  two  classes   One  class  “contains”  another  class:  the  has-­‐a  rela)onship   -­‐     Composi)on:  the  contained  item  is  part  of  the   containing  item  (an  engine  in  a  car)   -­‐   Aggrega)on:  the  contained  item  is  part  of  a  collec)on  of   items(airplanes  in  an  airport)   One  class  “uses”  another  class:  the  uses-­‐a  rela)onship   One  class  “creates”  another  class   3 .

The name of the attribute. private (-).Class  Diagram   A  rectangle  represents  a  class. protected (#). the data type of the attribute 4 .   Three  aspects  to  the  rectangle/class  are:   The  name  of  the  class   The  data  members  of  the  class   The  methods  of  the  class   Example   Scope identifier (Public (+). colon.

                   A  aggregates  B                      A  is  composed  of  B                    B  is  derived  from  A                  A  depends  on  B   5 .  The  most  common  follow.UML  Nota)on  for  Rela)onships                  You  can  use  UML  to  notate  which  accessibility  you  want   each  member  to  have.

s.  Composi)on   Class  diagram.  showing  the  has  rela)onship  between  an   airport  and  aircra\  as  well  as  an  is-­‐a  rela)onship  between   a  Jet/Helicopter  and  the  Aircra\.Aggrega)on  v.   6 .

 Composi)on                    Technically.  In  UML   this  is  shown  by  wri)ng  the  name  of  the  class  in   italics.s.   7 .Aggrega)on  v.  the  Aircra\  is  an  abstract  class.

 it  shows  that  a  car  is  dependent  upon  a  gas   sta)on.  In  addi)on.   8 .s.Aggrega)on  v.  Here  1  car  has  4  or  5   )res.  Composi)on   UML  will  also  allow  you  to  show  cardinality.

  They  improve  the  modifiability  and  maintainability  of   code   Good  Rules  for  OOD  are:   •   Deign  to  Interfaces   •   Favor  aggrega)on  over  inheritance   •   Find  what  varies  and  encapsulate  it   9 .A  Recap:  Why  Design  Pa3ern  ?   Pa3erns  help  us  communicate  be3er.

  Intent:  The  purpose  of  the  pa3ern.   Solu0on:  How  the  pa3ern  provides  a  solu)on  to  the  problem  in  the   context  in  which  it  shows  up.   Consequences:  The  consequences  of  using  the  pa3ern.  we  will  describe  them   using  the  following  structure:   Name:  All  pa3erns  will  have  a  unique  name  that  iden)fies  them.     Generic  Structure:  A  standard  diagram  that  shows  a  typical   structure  for  the  pa3ern   10 .   Par0cipants  and  collaborators:  The  en))es  involved  in  the  pa3ern.   Implementa0on:  How  the  pa3ern  is  implemented.Design  Pa3erns   When  we  study  so\ware  design  pa3erns.   Problem:  The  problem  that  the  pa3ern  is  trying  to  solve.

Design  Space  for  GoF  Pa3erns   Scope: domain over which a pattern applies Purpose: reflects what a pattern does 11 .

  We  need  to  create  a  shape  class  and  have  the  concrete  classes  of   point.  and  square  derive  from  shape  as  in  the  following  figure:   12 .  line.Adapter  Pa3ern   This  is  a  problem  that  cries  out  for  polymorphism.

  A  Shape  must  be  able  to:     Set  it’s  loca)on   Get  it’s  Loca)on   Display  itself   Fill  itself   Set  it’s  color   Undisplay  itself   A  more  detailed  UML  specifica)on:   13 .   Line.Adapter  Pa3ern   We  define  a  series  of  behaviors  (methods)  that  all  Shapes  will  have  in  common  in   the  Shape  class  and  then  override  their  behavior  in  the  concrete  classes  of  Point.  and  Square.

  •   fillIt().  and     I  already  have  an  XXCircle  class  that  handles  all  the  func)onali)es     requirde  but  with  a  different  interface:   •   displayIt().   Should  I  rewrite  class?     14 .   •   undisplayIt().Example     What  if  I  need  to  add  a  class  for  circle.

Example     Create  a  Circle  object  that  encapsulates  XXCircle  by  making  an   XXCircle  object  an  a3ribute  of  the  Circle  class.   15 .

Sample  Code   Some  sample  code  to  help  you  see  how  the  adapter  works:   Class  Circle  extends  Shape  {        …        private  XXCircle  myXXCircle.        …        public  Circle  ()  {              myXXCircle  =  new  XXCircle().        }        void  public  display()  {              myXXCircle.displayIt().        }        …   }   16 .

  17 .   Solu0on:  Provides  a  wrapper  with  the  desired  interface.  but  the  wrong   interface.   Implementa0on:  Contain  the  exis)ng  class  in  another  class.  Have   the  containing  class  match  the  required  interface  and  call  the   methods  of  the  contained  class.  Adapter  Pa3ern   Intent:  Match  an  exis)ng  object  beyond  your  control  to  a   par)cular  interface   Problem:  A  system  has  the  right  data  and  behavior.   Consequences:  Allows  for  preexis)ng  objects  to  fit  into  new  class   structures.  Allows  the   Client  to  use  the  Adaptee  as  if  it  were  a  type  of  Target.   P  &  C:  Adapters  Target  (the  class  it  derives  from).

Adapter  Pa3ern  Structure   18 .

  19 .  Façade  defines  a  higher  level  interface  that   makes  a  subsystem  easier  to  use.  Facade  Pa3ern  Revisit   What  GoF  said:       Provide  a  unified  interface  to  a  set  of  interfaces  in  a   subsystem.   It’s  basically  saying  that  we  need  a  simpler  way  to  access  a  complex   system.

  20 .  Facade  Pa3ern   Typically  the  façade  works  with  a  client  wan)ng  to  access  a  subset   of  the  overall  subsystem.

 but  reduces  op)ons.     Solu0on:  Create  a  new  interface  for  the  client  to  use.   Problem:  You  need  to  use  only  a  subset  of  a  complex  system.   Implementa0on:  Define  a  new  class  (or  classes)  that  has  the  required  interface   and  uses  the  exis)ng  system.  Facade  Pa3ern     Intent:  You  want  to  simplify  how  to  use  an  exis)ng  system.   Par0cipants  and  Collaborators:  Simplified  interface  for  client   Consequences:  Simplifies  the  us  of  a  required  subsystem.  You  need  to  define   your  own  interface.   21 .

Example   Complexity  can  be  greatly  reduced  for  the  applica)on  that  accesses   a  façade  instead  of  a  or  many  subsystems:   22 .

 Adapter  v.s.  Facade   Differences  between  Adapter  and  Façade                             Façade        Adapter   Are  there  preexis)ng  classes?             Yes                Yes   Is  there  an  interface  we  MUST  design  to?       No         Yes   Does  an  object  need  to  behave  polymorphically?   No       Probably   Is  a  simpler  interface  needed?             Yes         No   23 .