Lezione 6b: Design Pattern Strutturali

1,415 views

Published on

Design Pattern Strutturali
• Decorator
• Facade
• Proxy

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,415
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lezione 6b: Design Pattern Strutturali

  1. 1. Decorator ✦ Noto anche come: Wrapper ✦ Il problema • si vuole aggiungere delle responsabilità a un oggetto (Component) senza cambiarne l’interfaccia • l’aggiunta deve essere effettuata a run time; oppure ci sono più aggiunte utilizzabili in combinazioni diverse; oppure deve essere possibile rimuovere a run time le responsabilità aggiuntive; quindi non è possibile usare l’ereditarietà 22
  2. 2. Decorator ✦ Soluzione • si definisce una classe Decorator che implementa l’interfaccia di Component • il Decorator mantiene un riferimento al Component che viene “decorato” • l’implementazione delle operazioni di Component nella classe Decorator richiama l’implementazione del componente decorato, ma ha la possibilità di fare delle pre- o post-elaborazioni, e in alcuni casi di saltare la chiamata al componente decorato 23
  3. 3. Decorator ✦ Esempio di struttura 24
  4. 4. Decorator ✦ Conseguenze • il comportamento aggiuntivo è trasparente per gli utenti del componente (sostituendo i riferimenti al Decorator al posto dei riferimenti al componente iniziale) • è possibile applicare più Decorator in cascata • l’insieme dei Decorator può essere deciso a run time (ad esempio in base alla configurazione), ed è possibile rimuovere un decoratore durante l’esecuzione 25
  5. 5. Decorator ✦ Esempio • la libreria di I/O di Java 26
  6. 6. Decorator ✦ Esempio • in una gerarchia di componenti visuali possiamo usare i Decorator per elementi opzionali come i bordi o le scrollbar 27
  7. 7. Decorator ✦ Esempio (continua) Nota: la classe javax.swing.JScrollPane implementa questo pattern in Java 28
  8. 8. Decorator ✦ Questo pattern è utilizzato spesso per aggiungere a un oggetto responsabilità che non riguardano “cosa” viene fatto, ma “come”: • logging • gestione delle transazioni • caching • sincronizzazione 29
  9. 9. Facade ✦ Il problema • spesso all’interno di un sistema ci sono sottosistemi complessi, costituiti da numerose interfacce e classi • si vuole rendere le funzioni (o un sottoinsieme delle funzioni) di un sottosistema accessibili in maniera semplificata, interagendo con una singola classe 30
  10. 10. Facade ✦ Soluzione • si realizza una classe di “facciata” (facade o façade, appunto), istanziata con i riferimenti agli oggetti che compongono il sottosistema da incapsulare • il client vede solo l’oggetto Facade; le operazioni su questo oggetto provvedono ad attivare gli oggetti del sottosistema incapsulato 31
  11. 11. Facade ✦ Esempio di struttura 32 fonte: http://en.wikipedia.org
  12. 12. Facade ✦ Conseguenze • l’interazione con il sottosistema incapsulato diventa più semplice • è possibile modificare il sottosistema incapsulato mantenendo inalterata l’interfaccia della Facade • PROBLEMA: non tutte le funzionalità del sottosistema incapsulato sono accessibili attraverso la Facade; in alcune situazioni il client deve comunque accedere alle funzioni di basso livello fornite direttamente dalle classi del sottosistema 33
  13. 13. Facade ✦ Esempio • la classe org.junit.runner.JUnitCore è una “facciata” per accedere al sottosistema di JUnit che si occupa di lanciare i test 34
  14. 14. Facade ✦ Esempio 35
  15. 15. Proxy ✦ Il problema • in alcuni casi è necessario usare un oggetto (Proxy) per fare le veci di un altro oggetto (Subject) • il motivo per usare un “surrogato” è che l’accesso al Subject reale è complesso, e si vuole nascondere questa complessità al client 36
  16. 16. Proxy ✦ Soluzione • si realizza un oggetto Proxy che implementa la stessa interfaccia del Subject • l’invocazione dei metodi del Proxy determina l’invocazione dei corrispondenti metodi del Subject reale, passando attraverso l’impiego degli appropriati meccanismi di accesso e comunicazione (nascosti al client) 37
  17. 17. Proxy ✦ Esempio di struttura 38 fonte: http://en.wikipedia.org
  18. 18. Proxy ✦ Conseguenze • il Proxy fornisce un livello di indirezione nell’accesso al Subject reale; questo livello può essere utilizzato per nascondere al client la complessità dei meccanismi di accesso ✦ Proxy vs Decorator • la differenza tra i due pattern è spesso sfumata; in generale: ‣ un Decorator ha il compito di aggiungere responsabilità a un oggetto ‣ un Proxy ha il compito di nascondere il meccanismo con cui si accede a un oggetto 39
  19. 19. Proxy ✦ Caso notevole: Remote Proxy • il Subject reale si trova in un processo diverso da quello del client, possibilmente su un altro computer; il Subject reale potrebbe anche girare su una diversa piattaforma o essere scritto in un diverso linguaggio di programmazione • in questo caso il Proxy si occupa dei dettagli della comunicazione, usando i servizi di Inter-Process Communication e di rete offerti dal sistema operativo, e (se necessario) adattando le differenze tra linguaggi di programmazione 40
  20. 20. Proxy ✦ Caso notevole: Virtual Proxy (Lazy Instantiation) • il Subject reale è un oggetto costoso da istanziare, e si vuole evitare di crearlo fino al momento in cui deve essere effettivamente usato • il Proxy effettua la creazione del Subject reale solo quando viene richiamato per la prima volta un metodo che non può essere gestito direttamente dal Proxy stesso 41
  21. 21. Proxy ✦ Caso notevole: Future • il Subject reale è il risultato di una lunga operazione, e non si vuole bloccare il resto del programma fino al suo completamento • il Subject viene prodotto in un thread secondario; il Proxy riceverà il risultato al termine dell’operazione, ma nel frattempo può essere passato ad altre parti del programma • se viene richiamato un metodo del Proxy e il Subject reale non è ancora pronto, il Proxy introduce un’attesa, o restituisce un valore nullo ‣ se il Subject è parzialmente costruito, il Proxy potrebbe rendere disponibili i metodi che hanno senso in base alle informazioni già prodotte 42
  22. 22. Proxy ✦ Esempio • le immagini nella libreria AWT sono gestite attraverso proxy: alla creazione di un oggetto della classe Image (effettuata dal factory method Toolkit.createImage) viene restituito un proxy, mentre un thread separato provvede a caricare l’immagine dal disco o dalla rete; è possibile cominciare a usare il proxy prima che il caricamento sia completato (ad esempio per conoscere le dimensioni dell’immagine) 43
  23. 23. Proxy ✦ Caso notevole: Smart Proxy • il Subject implementa meccanismi speciali per l’allocazione/deallocazione, e si vuole che questi meccanismi siano nascosti al client ‣ Esempio: Reference Counting ‣ Esempio: Copy On Write • il Proxy è un oggetto che usa i meccanismi di allocazione/deallocazione normali, e gestisce i meccanismi speciali richiesti dal Subject reale 44
  24. 24. Proxy ✦ Esempio • la classe string della standard library del C++ usa uno Smart Proxy per nascondere l’allocazione dinamica (C++ non ha la garbage collection) ‣ lo Smart Proxy usa il reference counting per decidere quando la stringa vera e propria deve essere deallocata ‣ lo Smart Proxy usa il Copy On Write per evitare di dover creare una copia della stringa ogni volta che viene passata per valore a un sottoprogramma 45
  25. 25. Proxy ✦ Caso notevole: Protection Proxy • per la security occorre aggiungere dei controlli nell’accesso alle operazioni del Subject; questi controlli non sono però previsti dalla classe del Subject reale ‣ Esempio: uso in un contesto “untrusted”, come una applicazione scaricata da Internet, di una classe pensata per un contesto “trusted” • il Proxy effettua i controlli prima di richiamare il corrispondente metodo del Subject reale 46

×