Design pattern

Strutturali 2
Alfredo Milani
Dipartimento di Matematica e Informatica
Università degli Studi di Perugia
 Classificazione dei pattern

Strutturali
Creazionali
Comportamentali
1. Adapter 8. Factory 13. Template Method
(Adattatore) Method (Metodo sagoma)
2. Façade (Metodo 14. Strategy (Strategia)
(Facciata) fabbrica) 15. State (Stato)
3. Composite 9. Abstract
16. Command (Comando)
(Composto) Factory
(Fabbrica 17. Observer (Osservatore)
4. Decorator 18. Mediator (Mediatore)
(Decoratore) astratta)
10. Singleton 19. Memento (Memento,
5. Bridge Ricordo)
(Ponte) (Singoletto)
11. Prototype 20. Iterator (Iteratore)
6. Proxy
(Proxy) (Prototipo) 21. Visitor (Visitatore)
12. Builder 22. Chain of Responsibility
7. Flyweight
(Peso piuma) (Costruttore) (Catena di responsabilità)
© A. Milani - Design pattern
23. Interpreter (Interprete) 2
 Sommario

Esercizio Caffè 110

Altri pattern:

Proxy

Flyweight

© A. Milani - Design pattern 3

 Diagramma Class Adapter
<<Interface>> Adatt ato
Cliente
Obiettivo
+ m'()
+ m()

Obiettivo x; ClassAdapter
...
x.m(); m -> thi s.m '();
+ m()

© A. Milani - Design pattern 4

 Diagramma Object Adapter
Cliente Obiettivo Adattato

+ m() + m'()

ObjectAdapter
Obiettivo x;
... -adattato
x.m(); + m()
m -> adattato.m'()

Nota: Object Adapter non eredita…

© A. Milani - Design pattern 5
 Diagramma Façade

sottosistema
C1

Cl ie nt Facade

C4
C2

C5 C6

C3

© A. Milani - Design pattern 6

 Diagramma Composite
Component
Cl ient

+ operation()
+ add() n
+ remove()
+ getChildren()

Leaf Composite

+ operation() + operation()
+ add() -children
+ remove()
+ getChilldren()

© A. Milani - Design pattern 7

 Diagramma Decorator
Cliente Componente

+ operazione() 1

Componente Co ncret o Decoratore -decorato

+ operazione() + operazione()
operazione ->
decorato.op erazione()

Decoratore2 Decoratore1
- statoAggiunto
+ operazio ne()
+ com portam entoAggiunti vo() + operazione()

operazione ->
super.ope razi one();
comport amentoAgg iunt o();
© A. Milani - Design pattern 8
 Esercizio

Caffè 110

Vende “cibarie”

Pizze, calzoni, toast, tramezzini, piadine, panini,
focacce, …

Con ingredienti a scelta fra:

Prosciutto, formaggio, mozzarella, funghi, spinaci,
speck, gorgonzola, nutella, marmellata, …

Eventualmente “doppi” o “tripli” o …

Non modellate tutta la gestione, solo le classi
che consentano la creazione di cibarie
© A. Milani - Design pattern 9
 Caffè 110 1/4

Tutte le combinazioni, una classe per ognuna

PizzaAlProsciutto, PiadinaNutella,
PizzaMozzarellaERucola,
PizzaNutellaEAsparagi, …

Eventualmente usiamo l’ereditarietà

Problemi:

Con N cibi e M ingredienti ci sono N*M
combinazioni. Servono proprio tutte ste classi?

Eliminiamo PizzaNutellaEAsparagi e simili?

© A. Milani - Design pattern 10

 Caffè 110 2/4
Cibaria

Pizza Calzone Toast Tram ezzi no Piadina Panino Focaccia

…
Ingredienti

Prosciutto Mozzarella Funghi Formaggio Spinaci Nutella Marmellata

…

Come li combiniamo?
© A. Milani - Design pattern 11
 Caffè 110 3/4
Cibaria -ingredienti

Così?

Pi zza Calzone Toast Tramezzino Piadina Panino Focaccia

…

Ingredienti
0.. n

Prosciutto Mozzarella Funghi Formaggio Spinaci Nutella Marmellata

…

© A. Milani - Design pattern 12

 Caffè 110 4/4

Cliente Cibaria

Cibaria c1 =
new ConMarmellata( CibariaDiBase Ingredienti
new ConProsciutto(
new ConProsciutto(
new Pizza());
Cibaria c2 = new Pizza());
Cibaria c3 =
new ConMarmellata(
Pizza … Focaccia ConProsciutto
… ConMarmellata

new ConAsparagi(
new ConProsciutto(
new Focaccia());

© A. Milani - Design pattern 13

 Caffè 110

È un Decoratore?

Che responsabilità/funzionalità aggiungo?

È un Composite?

Però aggiungo un solo ingrediente alla volta, non
raggruppo…

un po’ Decoratore senza aggiunta di
funzionalità, un po’ Composite “degenere”…

© A. Milani - Design pattern 14

 6. Proxy

Scopo

Fornire un surrogato o un segnaposto per un
oggetto

Per controllarne l’accesso

Esempi

Per efficienza: In un word processor, caricare
le figure solo al bisogno evitando di caricarle
tutte all’inizio

Per sicurezza: Segnaposto che controlla e
gestisce i privilegi d’accesso

…
© A. Milani - Design pattern 15
 Segnaposto in word processor
Figure
WordProc essor
- dim : Dimension

+ draw()
+ getDimension()
+ store()
+ load()

ProxyFigure RealFigure
- fileName - ...implementation...
-figure
getDimension() -> + draw() + draw()
if (figure==null) + getDimension() + getDimension()
return figure.getDimension(); + store() + store()
else + load() + load()
return dim;

© A. Milani - Design pattern 16

 Diagramma del Proxy
Subject
Client

+ request()

Proxy -real RealSubject

+ request() + request()

request ->
...
real.request();

Commento
...
Pattern facile

Altro tipo di “wrapper”

© A. Milani - Design pattern 17

 4 tipi di Proxy

Proxy remoto

Rappresentante locale per oggetto in spazio ≠
(Es.: RMI, Remote Method Invocation)

Proxy virtuale

Gestisce la creazione su richiesta di oggetti
“costosi” (Es.: immagine in word processor)

Proxy di protezione

Gestisce diritti di accesso ≠ per oggetti ≠

Riferimento intelligente

Sostituisce un puntatore (Es.: #riferimenti per
gestire la distruzione)
© A. Milani - Design pattern 18
 Copy-on-write

Uso tipico del Proxy

Copia di un oggetto grande/complicato

Costosa

E magari inutile, se non modifico…

Soluzione:

Non copio, metto un Proxy che controlla l’accesso

E copia solo quando l’oggetto viene modificato

© A. Milani - Design pattern 19

 7. Flyweight (Peso piuma)

Scopo

Usare la condivisione di oggetti/istanze

per rappresentare in modo efficiente un gran
numero di oggetti

[a granularità fine (?)]

Migliorare le prestazioni (usare meno
memoria)

“Performance hack” [Eckel]

© A. Milani - Design pattern 20

 X L’idea
- x1
Cliente - x2
- ...
- xn

…
Flyweight
X' -flyweight - x2
Tanti Cliente
- x1 - ...
(10^6) - xn

… …

© A. Milani - Design pattern

Pochi 21
 Stati “interno” ed “esterno”
Il flyweight distingue tra due tipi di stato

“Interno” (al flyweight) o intrinseco

Indipendente dal contesto, condiviso fa risparmiare
memoria

“Esterno”

Dipendente dal contesto, individuale, può essere
memorizzato fuori del flyweight e fornito all’oggetto se
necessario

Esempio

Caratteri in un word processor

Condiviso: rappresentazione font true type, funzioni per scalare, …

Individuale: dimensione, stile, posizione

© A. Milani - Design pattern 22

 Flyweight. Esempio C++
WordProcessor(1/2)

© A. Milani - Design pattern 23

 Flyweight. Esempio C++
WordProcessor(1/2)

Notare che gli oggetti GraphicChar associati ai

due caratteri “l” vengono creati una sola volta
© A. Milani - Design pattern 24
 Il Diagramma del FlyWeight

© A. Milani - Design pattern 25

 I Ruoli nel FlyWeight

Flyweight (Character)

Divhisrs uns interfaccia attraversoc ui flyweight può ricevere lo stato esterno o agire su
di esso.

ConcreteFlyweight (CharacterA, CharacterB, ..., CharacterZ)

Implementa l’interfaccia del Flyweight e aggiunge la memoria per lo stato instrinseco.
Un oggetto ConcreteFlyweight deve essere condivisibile e con stato indip. dal contesto.

UnsharedConcreteFlyweight ( non usato sempre )

Non tutte le sottoclassi Flyweight hanno bisogno di essere condivise.L’interfaccia
consente lacondivisione ma non obbliga. È comune per UnsharedConcreteFlyweight
avere come figli oggetti di tipo ConcreteFlyweight objects .

FlyweightFactory (CharacterFactory)

Crea e gestisce gli oggetti flyweight

Assicura che il flyweight opportunamente condiviso. Quando un client richiede un
flyweight, la FlyweightFactory ne fornisce una istanza se esiste, altrimenti ne crea uno.

Client (FlyweightApp) mantiene un riferimento ai flyweight.

Calcola o memorizza lo stato estrinseco (esterno)dei flyweight.

© A. Milani - Design pattern 26

 Commenti

Più utile se tanti oggetti con duplicazione dati

Attenzione ai confronti con “==”!!

Flyweight vs. Decorator

Decorator: esplosione combinatoria classi

Flyweight: esplosione combinatoria oggetti

Spesso usato insieme al Composite per
condividere le foglie Component

Spesso utilizzato il

Factory per la creazione dei Leaf Composit e

flyweight
Flyweight
© A. Milani - Design pattern 27