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

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

Decorator
✦ Esempio di struttura
24

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

Decorator
✦ Esempio
• la libreria di I/O di Java
26

Decorator
✦ Esempio
• in una gerarchia di componenti visuali possiamo
usare i Decorator per elementi opzionali come i
bordi o le scrollbar
27

Decorator
✦ Esempio (continua)
Nota: la classe javax.swing.JScrollPane
implementa questo pattern in Java
28

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

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

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

Facade
✦ Esempio di struttura
32 fonte: http://en.wikipedia.org

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

Facade
✦ Esempio
• la classe org.junit.runner.JUnitCore è una
“facciata” per accedere al sottosistema di JUnit
che si occupa di lanciare i test
34

Facade
✦ Esempio
35

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

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

Proxy
✦ Esempio di struttura
38 fonte: http://en.wikipedia.org

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

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

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

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

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

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

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

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