Design patterns - parte 1

1,271 views
1,148 views

Published on

The design patterns are recurring solutions to common problems in software design.
The design patterns in computer science were formally described for the first time in the book "Design Patterns: Elements of Reusable Object-Oriented Software", whose authors are often called the Gang of Four, GoF or Go4.

Published in: Technology

Design patterns - parte 1

  1. 1. PATTERN  ARCHITETTRALI  
  2. 2. Pa#ern   è   un   termine   inglese   che   può   essere   trado>o,   a   seconda   del   contesto,   con   disegno,   modello,   schema,   schema   ricorrente   e,   in   generale,   può   essere   u@lizzato   per   indicare   una   regolarità   che   si   riscontra   all'interno   di   un   insieme   di   oggeD   osserva@   oppure  la  regolarità  che  si  osserva  nello  spazio  e/o  nel  tempo  in   determina@  fenomeni  dinamici.  
  3. 3. fabio.armani  
  4. 4. Overview   •  •  •  •  •  •  •  •  Analysis  pa>erns   Architectural  pa>erns   Design  pa>erns   Enterprise  pa>erns   GRASP  pa>erns   Implementa@on  pa>erns   J2EE  Core  pa>erns   SCM  pa>erns  
  5. 5. Overview   •  Design  Pa>ern   –  Stru>ura  di  un  pa>ern     –  Classificazione  dei  design  pa>ern    
  6. 6. Design  Pa>erns   •  I  design  pa>erns  sono  soluzioni  ricorren@  a  problemi  comuni  nel   campo  del  soTware  design     •  I  design  pa>erns  in  ambito  informa@co  vengono  formalmente   descriD  per  la  prima  volta  nel  libro  Design  Pa*erns:  Elements  of   Reusable  Object-­‐Oriented  So<ware,  i  cui  autori  vengono  spesso   chiama@  la  Gang  of  Four  o  GoF  o  Go4   •  I  design  pa>erns  NON  rappresentano  la  proge>azione  completa  di   una  soluzione,  che  può  essere  trasformata  dire>amente  in  codice     •  Essi  rappresentano  piu>osto  la  descrizione  di  come  risolvere  un   problema  che  può    sorgere  in  differen@  situazioni.  I  design  pa>erns   sono  una  sorta  di  template  rispe>o  alla  soluzione  di  problemi   ricorren@  in  determina@  campi  dell’informa@ca  
  7. 7. Design  Pa>erns   •  I  design  pa>erns  possono  velocizzare  il  processo  di  sviluppo  del   soTware  fornendo  paradigmi  di  programmazione  prova@  e  testa@     •  I  design  pa>erns  forniscono  soluzioni  generali,  documentate  in  un   formato  che  non  richiede  specifiche  legate  ad  un  par@colare   problema     •  I  design  pa>erns  cos@tuiscono  un  veicolo  per  la  comunicazione   inerente  la  proge>azione  e  le  archite>ure  soTware  
  8. 8. Design  Pa>erns  >  libri  
  9. 9. Stru>ura  di  un  pa>ern   •  Un  pa>ern  può  avere  una  precisa  stru>ura  che  lo  descrive  
  10. 10. Stru>ura  di  un  pa>ern   •  nome:  iden@fica  il  pa>ern  e  deve  rappresentarlo  il  più   possibile  (es:  Factory)   •  descrizione:  una  breve  descrizione  dell’obbieDvo  del  pa>ern,   corrispondente  in  quasi  tuD  i  casi  al  “intent”  del  libro  di  GoF     •  problema:  rappresenta  la  descrizione  della  situazione  alla   quale  si  può  applicare  il  pa>ern     •  soluzione:  rappresenta  la  descrizione  degli  elemen@  cos@tu@vi   del  proge>o  con  le  loro  relazioni,  senza  però  scendere  nei   de>agli  implementa@vi.  Quello  che  si  vuole  descrivere  infaD   è  un  problema  astra>o  e  la  rela@va  configurazione  di   elemen@  ada>a  a  risolverlo    
  11. 11. Stru>ura  di  un  pa>ern   •  stru5ura  del  pa5ern:  diagramma  di  classi  in  UML  della   stru>ura  generica  del  pa>ern   •  applicazione  del  pa5ern:  offre  un  diagramma  UML  delle  classi   del  problema,  presenta  l’abbinamento  delle  classi  del   problema  con  le  classi  che  descrivono  la  stru>ura  conce>uale   del  pa>ern,  descrive  l’implementazione  del  il  codice  Java,  e   presenta  e  commenta  gli  output  dell’esecuzione   •  osservazioni  sull’implementazione  in  Java:  presenta  gli  aspeD   par@colari  che  riguardano  l’implementazione  del  pa>ern  in   Java  
  12. 12. Stru>ura  di  un  pa>ern   •  conseguenze:  i  risulta@  e  i  vincoli  derivan@  dall’applicazione   del  pa>ern.  Essi  sono  fondamentali,  in  quanto  possono   risultare  determinan@  nella  scelta  del  pa>ern  stesso:  le   conseguenze  comprendono  considerazioni  legate  alle  risorse   computazionali  (tempo  e  memoria),  possono  descrivere  le   implicazioni  del  pa>ern  con  alcuni  linguaggi  di   programmazione  e  l’impa>o  di  quest’ul@mo  con  il  resto  del   proge>o    
  13. 13. Classificazione  dei  design  pa>ern   •  Ci  sono  diversi  criteri  per  classificare  i  design   pa>erns,  i  più  comuni  dei  quali  sono  quelli  che   evidenziano  il  @po  di  problema  che  si  cerca  di   risolvere     •  Nel  suo  libro,  la  Gang  Of  Four  individuò  23   design  pa>ern  suddivisi  in  tre  categorie.  :   stru>urali,  creazionali  e  comportamentali    
  14. 14. PATTERN  CREAZIONALI  
  15. 15. Classificazione  dei  design  pa>ern   •  Pa*ern  Creazionali:  rendono  i  componen@  del   sistema  che  usano  determina@  oggeD  indipenden@   da  come  tali  oggeD  sono  sta@  crea@,  compos@  e   rappresenta@.   •  I  pa>ern  creazionali  nascondono  i  costru>ori  delle   classi  e  me>ono  al  loro  posto  dei  metodi  creando   un’interfaccia.   •  In  questo  modo  si  possono  u@lizzare  oggeD  senza   sapere  come  sono  implementa@.  
  16. 16. Pa>ern  creazionali   •  L'Abstract  factory  (le>eralmente,  "fabbrica  astra>a")  fornisce   un'interfaccia  per  creare  famiglie  di  oggeD  connessi  o  dipenden@  tra  loro,   in  modo  che  non  ci  sia  necessità  da  parte  degli  u@lizzatori  di  specificare  i   nomi  delle  classi  concrete  all'interno  del  proprio  codice.   •  Il  Builder  ("costru>ore")  separa  la  costruzione  di  un  ogge>o  complesso   dalla  sua  rappresentazione,  in  modo  che  il  processo  di  costruzione  stesso   possa  creare  diverse  rappresentazioni.   •  Il  Factory  method  ("metodo  fabbrica")  fornisce  un'interfaccia  per  creare   un  ogge>o,  ma  lascia  che  le  so>oclassi  decidano  quale  ogge>o  istanziare.  
  17. 17. Pa>ern  creazionali   •  La  Lazy  ini?aliza?on  ("inizializzazione  pigra")  è  la  taDca  di  istanziare  un   ogge>o  solo  nel  momento  in  cui  deve  essere  usato  per  la  prima  volta.  È   u@lizzato  spesso  insieme  al  pa>ern  factory  method.   •  Il  Prototype  ("proto@po")  perme>e  di  creare  nuovi  oggeD  clonando  un   ogge>o  iniziale,  o  proto@po.   •  Il  Singleton  ("singole>o")  ha  lo  scopo  di  assicurare  che  di  una  classe  possa   essere  creata  una  sola  istanza.  
  18. 18. PATTERN  STRUTTURALI  
  19. 19. Classificazione  dei  design  pa>ern   •  Pa*ern  Stru*urali:  perme>ono  di  riu@lizzare   oggeD  esisten@,  u@lizzando  l’ereditarietà  e  il   polimorfismo  per  comporre  interfacce  diverse   o  implementazioni  di  una  stessa  interfaccia.   •  I  pa>ern  stru>urali  riguardano  il  modo  in  cui   più  oggeD  sono  collega@  tra  loro  per  formare   stru>ure  complesse.  
  20. 20. Pa>ern  stru>urali   •  L'Adapter  ("ada>atore")  converte  l'interfaccia  di  una  classe  in  una   interfaccia  diversa.   •  Bridge  ("ponte")  perme>e  di  separare  l'astrazione  di  una  classe  dalla  sua   implementazione,  per  perme>ere  loro  di  variare  indipendentemente.   •  Il  Composite  ("composto"),  u@lizzato  per  dare  la  possibilità  all'u@lizzatore   di  manipolare  gli  oggeD  in  modo  uniforme,  organizza  gli  oggeD  in  una   stru>ura  ad  albero.   •  Il  Container  ("contenitore")  offre  una  soluzione  alla  ro>ura   dell'incapsulamento  per  via  dell'uso  dell'ereditarietà.   •  Il  Decorator  ("decoratore")  consente  di  aggiungere  metodi  a  classi   esisten@  durante  il  run-­‐@me  (cioè  durante  lo  svolgimento  del  programma),   perme>endo  una  maggior  flessibilità  nell'aggiungere  delle  funzionalità  agli   oggeD.   •  Extensibility  ("estendibilità")  
  21. 21. Pa>ern  stru>urali   •  Il  Façade  ("facciata")  perme>e,  a>raverso  un'interfaccia  più  semplice,   l'accesso  a  so>osistemi  che  espongono  interfacce  complesse  e  diverse  tra   loro.   •  Flyweight  ("peso  piuma"),  che  perme>e  di  separare  la  parte  variabile  di   una  classe  dalla  parte  che  può  essere  riu@lizzata.   •  Proxy  fornisce  una  rappresentazione  di  un  ogge>o  di  accesso  difficile  o   che  richiede  un  tempo  importante  per  l’accesso  o  creazione.  Il  Proxy   consente  di  pos@cipare  l’accesso  o  creazione  al  momento  in  cui  sia   davvero  richiesto.   •  Pipes  and  filters  ("condoD  e  filtri")   •  Private  class  data  ("da@  di  classe  priva@")  
  22. 22. PATTERN  COMPORTAMENTALI  
  23. 23. Classificazione  dei  design  pa>ern   •  Pa*ern  Comportamentali:  riguardano   l’assegnazione  di  responsabilità  agli  oggeD,   incapsulando  il  comportamento  in  un  ogge>o   e  delegando  ad  esso  determinate  richieste.   •  I  pa>ern  comportamentali  forniscono   soluzione  alle  più  comuni  @pologie  di   interazione  tra  gli  oggeD    
  24. 24. Pa>ern  comportamentali   •  Chain  of  Responsibility  ("catena  di  responsabilità")  diminuisce   l'accoppiamento  fra  l'ogge>o  che  effe>ua  una  richiesta  e  quello  che  la   soddisfa,  dando  a  più  oggeD  la  possibilità  di  soddisfarla   •  Il  Command  ("comando")  perme>e  di  isolare  la  porzione  di  codice  che   effe>ua  un'azione  dal  codice  che  ne  richiede  l'esecuzione.   •  Event  Listener  ("ascoltatore  di  even@")   •  Hierarchical  Visitor  ("visitatore  di  gerarchia")   •  Interpreter  ("interprete")  dato  un  linguaggio,  definisce  una   rappresentazione  della  sua  gramma@ca  insieme  ad  un  interprete  che   u@lizza  questa  rappresentazione  per  l'interpretazione  delle  espressioni  in   quel  determinato  linguaggio.   •  L'Iterator  ("iteratore")  risolve  diversi  problemi  connessi  all'accesso  e  alla   navigazione  a>raverso  gli  elemen@  di  una  stru>ura  da@,  senza  esporre  i   de>agli  dell'implementazione  e  della  stru>ura  interna  del  contenitore.  
  25. 25. Pa>ern  comportamentali   •  Il  Mediator  ("mediatore")  si  interpone  nelle  comunicazioni  tra  oggeD,  allo   scopo  di  aggiornare  lo  stato  del  sistema  quando  uno  qualunque  di  essi   comunica  un  cambiamento  del  proprio  stato.   •  Il  design  pa>ern  Memento  ("promemoria")  è  l'operazione  di  estrarre  lo   stato  interno  di  un  ogge>o,  senza  violarne  l'incapsulazione,  e   memorizzarlo  per  poterlo  ripris@nare  in  un  momento  successivo.   •  L'Observer  ("osservatore")  definisce  una  dipendenza  uno  a  mol@  fra   oggeD  diversi,  in  maniera  tale  che  se  un  ogge>o  cambia  il  suo  stato,  tuD   gli  oggeD  dipenden@  vengono  no@fica@  del  cambiamento  avvenuto  e   possono  aggiornarsi.   •  Single-­‐serving  Visitor  
  26. 26. Pa>ern  comportamentali   •  State  ("stato")  perme>e  ad  un  ogge>o  di  cambiare  il  suo  comportamento   al  cambiare  di  un  suo  stato  interno.   •  Lo  Strategy  ("strategia")  è  u@le  in  quelle  situazioni  dove  è  necessario   modificare  dinamicamente  gli  algoritmi  u@lizza@  da  un'applicazione.   •  Il  Template  method  ("metodo  schema")  perme>e  di  definire  la  stru>ura  di   un  algoritmo  lasciando  alle  so>oclassi  il  compito  di  implementarne  alcuni   passi  come  preferiscono.   •  Il  Visitor  ("visitatore")  perme>e  di  separare  un  algoritmo  dalla  stru>ura  di   oggeD  compos@  a  cui  è  applicato,  in  modo  da  poter  aggiungere  nuovi   comportamen@  senza  dover  modificare  la  stru>ura  stessa.  
  27. 27. Design  Pa>erns  :  GoF   •  The  Sacred  Elements  of  the  Faith  
  28. 28. Design  Pa>erns  everywhere  
  29. 29. PATTERN  CREAZIONALI  
  30. 30. Gof  pag.  117   SINGLETON  
  31. 31. Singleton   Descrizione   •  Il  Singleton  è  un  design  pa>ern  creazionale  che  ha  lo  scopo  di   garan@re  che  di  una  determinata  classe  venga  creata  una  e   una  sola  istanza,  e  di  fornire  un  punto  di  accesso  globale  a   tale  istanza.  
  32. 32. Singleton   Esempio   •  Un  applica@vo  deve  istanziare  un  ogge>o  che  ges@sce  una   stampante.  Questo  ogge>o  deve  essere  unico,  vale  dire,  deve   esserci  soltanto  una  sola  istanza  di  esso,  altrimen@,   potrebbero  risultare  dei  problemi  nella  ges@one  della  risorsa.     •  Il  problema  è  la  definizione  di  una  classe  che  garan@sca  la   creazione  di  un'unica  istanza  all’interno  del  programma.    
  33. 33. Singleton   Problema   •  Bisogna  garan@re  che  la  classe  abbia  un’unica  istanza,   accessibile  a>raverso  un  unico  punto  di  ingresso  alla  classe   stessa.   •  Tipicamente  questo  si  verifica  quando  la  classe  man@ene   informazioni  che  devono  essere  condivise  da  più  par@   dell’applicazione  e  non  è  corre>o  oppure  non  è  efficiente  che   queste  informazioni  siano  duplicate    
  34. 34. Singleton   Soluzione   •  Il  “Singleton”  pa>ern  definisce  una  classe  della  quale  è   possibile  la  istanziazione  di  un  unico  ogge>o,  tramite   l’invocazione  a  un  metodo  della  classe,  incaricato  della   produzione  degli  oggeD.   •  Le  diverse  richieste  di  istanziazione,  comportano  la   res@tuzione  di  un  riferimento  allo  stesso  ogge>o.    
  35. 35. Singleton   Soluzione   •  Si  rende  il  costru>ore  della  classe  privato,  in  modo  che  non   sia  possibile  creare  dire>amente  istanze  di  tale  classe.   •  La  classe  viene  dotata  di  un  metodo  sta?c  per  o>enere   un’unica  istanza,  che  viene  memorizzata  in  un  campo  sta?c   privato  della  classe  stessa.  Tu>avia  possono  esserci  alcune   variazioni  a  tale  soluzione:     –  l’istanza  può  essere  creata  all’inizializzazione  del  programma,   oppure  la  prima  volta  che  viene  richiesta     –  l’istanza  può  appartenere  a  una  so>o  classe  della  classe   singleton  (come  accade  nel  Factory  Method)  
  36. 36. Singleton   Stru*ura    
  37. 37. Singleton   Schema  del  modello   •  Si  presenta  di  seguito  una  delle  implementazioni  più  semplici   del  Singleton:        
  38. 38. Singleton   PartecipanJ   •  Singleton:  classe  PrinterSpooler.     –  Definisce  un  metodo  getInstance  che  res@tuisce  un   riferimento  alla  unica  istanza  di  se  stessa.     –  E’  responsabile  della  creazione  della  propria  unica  istanza.      
  39. 39. Singleton   Implementazione   •  L'implementazione  più  semplice  di  questo  pa>ern  prevede   che  la  classe  singleton  abbia  un  unico  costru>ore  privato,  in   modo  da  impedire  l'istanziazione  dire>a  della  classe.    
  40. 40. Singleton   Implementazione      
  41. 41. Singleton   Implementazione  mulJ-­‐thread   •  In  applicazioni  mul@-­‐thread  l'u@lizzo  di  questo  pa>ern  con  la   lazy  ini?aliza?on  richiede  un'a>enzione  par@colare:  se  due   thread  tentano  di  eseguire  contemporaneamente  il   costru>ore  quando  la  classe  non  è  stata  ancora  istanziata,   devono  entrambi  controllare  se  l'istanza  esiste  e  soltanto  uno   deve  creare  la  nuova  istanza.    
  42. 42. Singleton   Sincronizzazione  esplicita   •  Il  modo  più  semplice  per  implementare  una  versione  thread-­‐ safe  è  quello  di  usare  un  meccanismo  di  sincronizzazione   come  quello  fornito  dalla  parola  chiave  synchronized  di  Java.   •  Tu>avia  questo  approccio  è  inefficiente:  infaD  la   sincronizzazione  è  u@le  solo  per  la  prima  inizializzazione,  e   cos@tuisce  un  inu@le  overhead  nelle  successive  chiamate  al   metodo  getter.      
  43. 43. Singleton   Sincronizzazione  esplicita      
  44. 44. Singleton   Sincronizzazione  implicita   •  In  alcuni  linguaggi  è  possibile  evitare  l'overhead  di   sincronizzazione  sfru>ando  quelle  peculiarità  della  lazy   ini?aliza?on  che  consentono  di  assicurarsi  la  presenza  del   singleton  in  memoria  all'a>o  del  suo  u@lizzo.   •  Le  modalità  specifiche  possono  variare  da  linguaggio  a   linguaggio;  ad  esempio,  in  Java  è  possibile  sfru>are  il  fa>o   che  l'inizializzazione  di  una  classe  ed  il  suo  caricamento  in   memoria,  quando  avvengono,  sono  operazioni  thread-­‐safe   che  comprendono  l'inizializzazione  di  tu>e  le  variabili  sta@che   (a>ribu@)  della  classe  stessa.    
  45. 45. Singleton   Sincronizzazione  implicita      
  46. 46. Singleton   Conseguenze   •  Con  il  singleton  si  ha  che:     –  l’accesso  alla  classe  è  controllato  e  avviene  a>raverso  l’unica   istanza  che  può  essere  creata     –  non  occorre  introdurre  variabili  globali  per  accedere  all’unica   istanza     –  è  semplice  estendere  la  classe  singleton  senza  modificare  il   codice  che  usa     –  è  semplice  passare  da  una  singola  istanza  a  più  istanze      
  47. 47. Singleton   CriJche   •  Alcuni  autori  hanno  cri@cato  il  pa>ern  Singleton,  osservando   che,  con  opportune  modifiche  stru>urali,  una  istanza  singola   può  entrare  più  efficacemente  a  far  parte  dell'Ambiente   globale  dell'applicazione  
  48. 48. ENTERPRISE  PATTERN  
  49. 49. Enterprise  Pa>erns   •  Pa>erns  of  Enterprise  Applica@on  Architecture   •  Core  J2EE  Pa>erns   •  Integra@on  Pa>erns  
  50. 50. Enterprise  Pa>erns  >  books  
  51. 51. Core  J2EE  Pa>erns   •  Presenta@on  Tier   •  Business  Tier   •  Integra@on  Tier  
  52. 52. Core  J2EE  Pa>erns   •  Presenta@on  Tier   –  –  –  –  –  –  –  –  Applica@on  Controller   Composite  View   Context  Object   Dispatcher  View   Front  Controller   Intercep@ng  Filter   Service  To  Worker   View  Helper  
  53. 53. Core  J2EE  Pa>erns   •  Business  Tier   –  –  –  –  –  –  –  –  –  Applica@on  Service   Business  Delegate   Business  Object   Composite  En@ty   Service  Locator   Session  Façade   Transfer  Object  (DTO)   Transfer  Object  Assembler   Value  List  Handler  
  54. 54. Core  J2EE  Pa>erns   •  Integra@on  Tier   –  –  –  –  Data  Access  Object  (DAO)   Domain  Store   Service  Ac@vator   Web  Service  Broker  
  55. 55. Presenta@on  Tier  Pa>ern   –  Applica@on  Controller   –  Composite  View   –  Context  Object   –  Dispatcher  View   –  Front  Controller   –  Intercep@ng  Filter   –  Service  To  Worker   –  View  Helper  
  56. 56. PoEAA  -­‐  pag.  117   FRONT  CONTROLLER  
  57. 57. FRONT  CONTROLLER  
  58. 58. FRONT CONTROLLER!
  59. 59. Front  Controller   Descrizione   •  Consente  di  ges@re  il  mapping  logico  delle  risorse    
  60. 60. Front  Controller   Problema   •  Si  vuole  fornire  un  punto  di  accesso  centralizzato  per  la   ges@one  delle  richieste  al  livello  dello  strato  di  presentazione,   in  modo  da  sparare  la  logica  di  presentazione  da  quella  di   processamento  delle  richieste  stesse.   •  Inoltre  si  vuole  evitare  di  avere  del  codice  duplicato  e  si  vuole   applicare  una  logica  comune  a  più  richieste.    
  61. 61. Front  Controller   Soluzione   •  Si  u@lizza  un  Front  Controller  come  punto  di  accesso  iniziale   per  ges@re  tu>e  le  richieste  connesse  tra  loro.   •  Il  Front  Controller  centralizza  la  logica  di  controllo  che   dovrebbe  altrimen@  essere  replicata  per  ogni  richiesta.    
  62. 62. Front  Controller   Use to Implement: •  Logical Resource Mapping •  Session Management •  Audit Logging Avoid: •  Physical Resource Mapping •  Unhandled Mapping in Multyplexed Resource Mapping strategy •  Logging of Arbitrary HTTTP Parameters •  Duplicating Common Logic Across Multiple Front Controllers Avoid: •  Invoking Commands Without Sufficient Authorization
  63. 63. Front  Controller  
  64. 64. Front  Controller  
  65. 65. Front  Controller  
  66. 66. Front  Controller   Conseguenze   •  Le  conseguenze  che  derivano  dall’u@lizzo  di  tale  pa>ern  sono:   –  –  –  –  centralizzazione  del  controllo   miglioramento  della  riusabilità   miglioramento  della  manutenibilità   separazione  dei  ruoli  all’interno  dell’applicazione    

×