PATTERN  ARCHITETTRALI  

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.  

fabio.armani  

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  

Overview  

•  Design  Pa>ern  –  Stru>ura  di  un  pa>ern    –  Classificazione  dei  design  pa>ern    

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  

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  

Design  Pa>erns  >  libri  

Stru>ura  di  un  pa>ern  •  Un  pa>ern  può  avere  una  precisa  stru>ura  che  lo  descrive  

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    

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  

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    

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  

 

PATTERN  CREAZIONALI  

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@.  

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.  

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.  

PATTERN  STRUTTURALI  

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.  

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à")  

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@")  

PATTERN  COMPORTAMENTALI  

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    

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.  

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  

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.  

Design  Pa>erns  :  GoF  •  The  Sacred  Elements  of  the  Faith  

Design  Pa>erns  everywhere  

PATTERN  CREAZIONALI  

SINGLETON  Gof  pag.  117  

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.  

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.    

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    

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.    

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)  

Singleton  

Stru*ura    

Singleton  

Schema  del  modello  •  Si  presenta  di  seguito  una  delle  implementazioni  più  semplici  

del  Singleton:    

   

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.    

 

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.  

 

Singleton  

Implementazione    

 

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.  

 

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.    

 

Singleton  

Sincronizzazione  esplicita    

 

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.  

 

Singleton  

Sincronizzazione  implicita    

 

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    

 

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  

ENTERPRISE  PATTERN  

Enterprise  Pa>erns  •  Pa>erns  of  Enterprise  Applica@on  Architecture  •  Core  J2EE  Pa>erns  •  Integra@on  Pa>erns  

Enterprise  Pa>erns  >  books  

Core  J2EE  Pa>erns  •  Presenta@on  Tier  •  Business  Tier  •  Integra@on  Tier  

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  

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  

Core  J2EE  Pa>erns  •  Integra@on  Tier  

–  Data  Access  Object  (DAO)  –  Domain  Store  –  Service  Ac@vator  –  Web  Service  Broker  

Presenta@on  Tier  Pa>ern  –  Applica@on  Controller  –  Composite  View  –  Context  Object  –  Dispatcher  View  –  Front  Controller  –  Intercep@ng  Filter  –  Service  To  Worker  –  View  Helper  

FRONT  CONTROLLER  PoEAA  -­‐  pag.  117  

FRONT  CONTROLLER  

FRONT CONTROLLER !

Front  Controller  

Descrizione  •  Consente  di  ges@re  il  mapping  logico  delle  risorse    

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.    

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.    

Front  Controller  Avoid: •  Physical Resource Mapping •  Unhandled Mapping in Multyplexed Resource Mapping

strategy •  Logging of Arbitrary HTTTP Parameters •  Duplicating Common Logic Across Multiple Front Controllers

Use to Implement: •  Logical Resource Mapping •  Session Management •  Audit Logging

Avoid: •  Invoking Commands Without Sufficient Authorization

Front  Controller  

Front  Controller  

Front  Controller  

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