Sistemi Informativi

Corso di Laurea Triennale in Ingegneria Informatica
Corso di Sistemi Informativi
A. A. 2004 - 2005
Design pattern
1
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Scopo
• Usare soluzioni già pronte (Riuso)
• Organizzare l’esperienza nella progettazione di software
a oggetti sotto forma di design pattern
2
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Definizione
• Secondo Gamma [1994] un pattern è composto da
quattro elementi:
–
–
–
–
3
Un nome
Il problema
La soluzione
Le conseguenze
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Il nome
• Deve fornire una descrizione del problema, le sue
soluzioni e le sue conseguenze
– Ovviamente la scelta del nome è difficile in quanto un nome
particolarmente eloquente è difficile da trovare, lo sforzo può
essere compensato da alcuni vantaggi, come la capacità di
esprimere indicazioni sul pattern stesso
4
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Il problema
• Una descrizione che deve chiarire in quali casi il pattern
è utilizzabile.
• Oltre al problema deve essere spiegato anche il contesto
a cui il pattern è adatto
5
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
La soluzione
• Vengono descritti tutti gli elementi di progettazione, le
associazioni tra di essi e i loro compiti.
• La descrizione dovrebbe sempre avere un carattere
astratto e non tentare di descrivere una specifica
soluzione
6
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Le conseguenze
• Si dovrebbero esporre tutti i possibili effetti, come i costi
o i limiti in termini di esecuzione o di occupazione di
memoria, in modo che fin dall’inizio si possa valutare
l’usabilità del pattern
7
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
1.
2.
3.
4.
5.
8
Perché usare i design pattern
Riuso
Esperienza dello sviluppatore
Innovazione
Integrazione
Comunicazione
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
1: Riuso
I design pattern traggono origine dall’esperienza, cosa che
facilita essenzialmente il riuso delle conoscenze (al
contrario delle teoria astratte che devono essere adattate
alle applicazioni concrete)
9
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
2: Esperienza dello sviluppatore
• Tutti i progettisti nel corso delle loro attività,
consapevolmente o inconsapevolmente, usano soluzioni
progettuali simili tra loro (anche in aree diverse).
• Inoltre, la progettazione di software valido dipende in
modo determinante dagli anni di esperienza dello
sviluppatore; per questo motivo è una buona idea
mettere a disposizione della comunità queste esperienze.
10
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
3: Innovazione
Le innovazioni tecniche possono essere diffuse con
successo.
11
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
4: Integrazione
Le tecniche più sperimentate possono essere integrate
senza rischi con le conquiste tecniche assolutamente
nuove, non ancora sufficientemente verificate
12
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
5: Documentazione
I pattern costruiscono un modo ben documentato di
diffondere la documentazione di progetto
13
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
6: Comunicazione
Con l’aiuto dei pattern, gli sviluppatori di software possono
comunicare le loro esperienze in fatto di design. Spesso
è difficile realizzare una comunicazione tecnica chiara e
comprensibile; i pattern possono rimediare a questo
problema
14
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche dei pattern
• Sono generali e astratti
• Descrivono piccole unità il che li porta ad avere una
elevata flessibilità
15
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Tipi di pattern
• Esistono tipologie di pattern che si occupano di risolvere
problemi di natura diversa:
–
–
–
–
16
Suddivisione dei compiti in un sistema
Cooperazione tra oggetti in un sistema
Pattern per la struttura di interi sistemi
Ecc.
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Pattern nella programmazione
orientata agli oggetti
• Un problema ricorrente nella programmazione orientata
agli oggetti è definire la giusta struttura di classi per la
soluzione di un problema:
– Esistono molti pattern che descrivono le strutture basilari o parti
di esse che è possibile estendere e adattare più facilmente
– Consentono di definire le dimensioni degli oggetti:
• Se devono essere di piccole dimensioni e racchiudere solo pochi dati
oppure contenere molti dati o un intero sottosistema
17
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche dei design pattern
• I design pattern si caratterizzano per
– Granularità
– Livello d’astrazione
• Criteri di classificazione
– Scopo: cosa fa il pattern
– Raggio d’azione: se si applica a classi o a oggetti
18
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Scopo dei pattern
• Un pattern è:
– Creazionale: riguarda il processo di creazione di oggetti
– Strutturale: ha a che fare con la composizione di classi e oggetti
– Comportamentale: si occupa del modo in cui classi o oggetti
interagiscono reciprocamente e distribuiscono le loro
responsabilità
19
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Raggio d’azione
• Class pattern: riguardano le relazioni fra classi e
sottoclassi
– Espresse attraverso l’ereditarietà ↔ statiche↔ fissate al
momento della compilazione
• Object pattern: riguardano relazioni fra oggetti:
– Possono essere cambiate durante l’esecuzione, sono dinamiche
– Sono i più numerosi
20
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
21
Creazionali
Abstract factory
Builder
Factory method
Prototype
Singleton
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
•
•
22
Strutturali
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
•
•
•
•
•
•
23
Comportamentali
Chain of responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template method
Visitor
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
Catalogo dei pattern
DEE - Politecnico di Bari
Scopo
Raggio d’azione
24
Creazionale
Strutturale
Comportamentale
Classi
Factory method
Adapter
Interpreter
Template Method
Oggetti
Abstarct factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Ingegneria del software
Marina
Mongiello
Corso di Laurea Triennale in Ingegneria Informatica
Corso di Sistemi Informativi
A. A. 2004 - 2005
Pattern strutturali
Adapter
Bridge
Decorator
Proxy
Facade
Flyweight
25
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Si occupano delle modalità di composizione di classi e oggetti per
formare strutture complesse
• Basati su classi:
– Utilizzano l’ereditarietà per comporre interfacce o implementazioni
• Basati su oggetti:
– Descrivono modalità di composizione di oggetti per realizzare nuove
funzionalità
– Forniscono maggiore flessibilità grazie alla possibilità di cambiare la
composizione durante l’esecuzione
• Adapter; Bridge; Decorator; Proxy
• Composite; Flyweight
• Facade
26
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adapter (o Wrapper) : scopo
• Convertire l’interfaccia di una classe in un’altra
interfaccia richiesta dal client.
• Consente a classi diverse di operare insieme quando ciò
non sarebbe altrimenti possibile a causa di interfacce
incompatibili.
27
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adapter: motivazione
• Una classe di supporto progettata con obiettivi di riuso,
talvolta può non essere riusabile perché la sua
interfaccia non è compatibile con l’interfaccia specifica
richiesta da un’applicazione
28
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adapter: esempio
• Un editor che consenta all’utente di disegnare e
comporre elementi grafici (linee, poligoni, testo, ecc) per
ottenere disegni e diagrammi
29
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
(Adapter ) Osservazioni
• Shape astratta: classe che definisce l’interfaccia per gli
oggetti grafici
• L’applicazione definisce una sottoclasse di Shape per
ciascuna tipologia di oggetto grafico:
– LineaShape per le linee
– PolygonShape per i poligoni ecc.
– TextShape più difficile da implementare
30
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
(Adapter) Problema/soluzione
• Problema: poter riusare la classe TextView per la
visualizzazione e la modifica del testo
– Gli oggetti TextView e Shape non possono essere usati in modo
intercambiabile
• Soluzioni:
– Modificare la classe TextView (ERRATA !)
– Definire TextShape in modo che adatti l’interfaccia TextView a
quella di Shape (Corretta)
31
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
(Adapter) Soluzione adottata
1. Ereditare l’interfaccia di Shape e l’implementazione di
TextView:
–
Pattern adapter basato su classi
2. Comporre un’istanza di TextView in una TextShape ed
implementare TextShape attraverso l’interfaccia di
TextView:
–
•
32
Pattern adapter basato su oggetti
Classe TextShape: adapter
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
Adapter (Esempio)
DEE - Politecnico di Bari
DrawingEditor
Shape
TextView
BoundingBox()
CreateManipulator()
Line
TextShape
BoundingBox()
CreateManipulator()
BoundingBox()
CreateManipulator()
GetExtent()
text
return->GetExtent()
return new TextManipulator
33
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
(Adapter) Osservazioni
• Oggetto adapter
• Richieste BoundingBox, dichiarate nella classe Shape
convertite in richieste GetExtent definite in TextView
• TextShape adatta TextView all’interfaccia Shape quindi
l’editor grafico può riusare la classe TextView che
altrimenti sarebbe incompatibile.
34
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
(Adapter) Vantaggi
• L’adapter fornisce funzionalità che la classe adattata non è in grado
di supportare:
– Nell’esempio:
• Un utente può trascinare ogni oggetto Shape in una nuova posizione in
maniera interattiva, ma la classe TextView non è stata progettata per
consentire ciò
• TextShape può consentire questa funzionalità mancante implementando
l’operazione CreateManipulator di Shape che ritorna un’istanza della
sottoclasse appropriata Manipulator.
• Manipulator è una classe astratta per oggetti che sanno muovere una Shape
come risposta a un’azione dell’utente (es. trascinamento di una figura verso
un’altra posizione)
35
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adater: applicabilità
• Il pattern può essere usato nei seguenti casi:
– Quando si vuole usare una classe esistente, ma la sua interfaccia
non è compatibile con quella desiderata
– Quando si vuole creare una classe riusabile in grado di cooperare
con classi non correlate o impreviste, cioè con classi che non
necessariamente hanno interfacce compatibili
36
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Client
Adapter: struttura (classi)
Target
Adaptee
Request()
SpecificRequest()
(implementation)
Adapter
Request()
•
37
SpecificRequest()
Una classe adapter utilizza l’ereditarietà multipla per adattare un’interfaccia
a un’altra
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Client
Adapter: struttura (oggetti)
Target
Adaptee
Request()
Adapter
SpecificRequest()
adaptee
Request()
•
38
adaptee->SpecificRequest()
Un oggetto adapter si basa invece sulla composizione di oggetti
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adapter: partecipanti
• Target (Shape)
– Definisce l’interfaccia specifica del dominio utilizzata dal client
• Client /DrawingEditor)
– Collabora con oggetti compatibili con l’interfaccia Target
• Adaptee (TextView)
– Individua un’interfaccia esistente che deve essere adattata
• Adapter (TextShape)
– Adatta l’interfaccia di Adaptee all’interfaccia Target
39
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione
class Shape {
public:
Shape();
virtual void BoundingBox(
Point &bottomLeft, Point& topRight) const;
virtual Manipulator *CreateManipulator () const;
};
class TextView{
public:
TextView();
void GetOrigin (Coord& x, Coord& y) const;
void GetExtent (Coord & width, Coord & height) const;
virtual bool IsEmpty() const;
};
La classe TextShape è adattatore tra queste due interfacce
40
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione (class pattern)
La classe adapter utilizza l’ereditarietà multipla per adattare le interfacce:
class TextShape: public Shape, private TextView{
public:
TextShape();
virtual void BoundingBox(
Point & bottomLeft, Point &topRight) const;
virtual bool IsEmpty() const;
virtual Manipulator* CreateManipulator() const;
};
41
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione
BoundingBox converte l’interfaccia di TextView in modo da renderla conforme a
Shape
void TextShape::BoundingBox (Point& bottomLeft, Point& topRight) const
{Coord bottom, left, width, height;
GetOrigin(bottom, left);
GetExtent(width, height);
bottomLeft = Point(bottom, left);
topRight =Point(bottom +height, left+width);
}
42
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione
L’operazione IsEmpty mostra un esempio di trasferimento delle richieste,
attività di base nell’implementazione degli adattatori:
bool TextShape::IsEmpty () const {
return TextView::IsEmpty();
}
CreateManipulator non è supportata da TextView (si suppone che la classe
textManipulator sia già implementata)
Manipulator* TextShape:: CreateManipulator() const{
return new TextManipulator(this);
}
43
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
Implementazione (object pattern)
L’oggetto adapter utilizza la composizione tra oggetti per combinare classi
con interfacce diverse.
L’adattatore TextShape mantiene un puntatore a TextView
class TextShape: Public Shape{
public:
TextShape(TextView*);
virtual BoundingBox(
Point& bottomLeft, Point& topRight) const;
virtual bool IsEmpty() const;
virtual Manipulator* CreateManipulator() const;
private:
TextView* _text;
};
44
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
Implementazione
TextShape deve inizializzare il puntatore all’istanza di TextView, e lo fa nel costruttore
Deve invocare le operazioni sull’oggetto TextView ogni volta che viene richiesta una sua operazione
Si suppone che il cliente crei l’oggetto TextView e lo passi al costruttore di TextShape
TextShape::TextShape (TextView* t){
_text=t;
}
void TextShape::BoundingBox( Point& bottomLeft, Point& topRight) const {
Coord bottom, left, width, height;
_text->GetOrigin(bottom, left);
_text->GetExtent(width, height);
bottomLeft =Point(bottom, left);
topRight(bottom+height,left+width);
}
bool TextShape::IsEmpty() const{
return _text->IsEmpty();
}
45
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Implementazione
L’implementazione di CreateManipulator non cambia rispetto alla versione
basata sulla classe adapter, poiché è implementata da zero e non riusa nulla
di TextView:
Manipulator* TextShape::CreateManipulator() const{
return new TextManipulator(this);
}
•
•
L’utilizzo di un oggetto adapter è una soluzione più flessibile
Es. la versione oggetto adapter di TextShape può operare senza modifiche
anche con sottoclassi di TextView, basta che il client passi un’istanza della
sottoclasse di Textview al costruttore di TextShape
46
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Adapter: pattern correlati
• Bridge
• Decorator
• Proxy
47
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Bridge
• Ha una struttura simile a quella di un oggetto adapter,
ma ha un obiettivo diverso:
– Separare un’interfaccia dalla sua implementazione in modo che
le due possano variare facilmente e indipendentemente
48
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Bridge: scopo
• (Detto anche Handle/Body)
• Disaccoppia un’astrazione dalla sua implementazione in
modo che le due possano variare indipendentemente
49
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Bridge: motivazione
• Rendere un’astrazione più flessibile:
– Se un’astrazione può avere più implementazioni possibili, si ricorre
all’ereditarietà:
• Una classe astratta definisce l’interfaccia dell’astrazione le sottoclassi la
implementano in modi differenti
• Svantaggio: Tale soluzione è poco flessibile perché lega un’implementazione
a un’astrazione in modo permanente:
– è difficile
» Modificare
» Estendere
» Riusare
– astrazioni e implementazioni in modo indipendente
50
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Il pattern bridge può essere usato nei seguenti casi:
1.
Evitare un legame permanente tra un’astrazione e la sua
implementazione

2.
3.
(se ad. L’implementazione deve essere selezionata o modificata durante
l’esecuzione)
Avere la possibilità di estendere sia le astrazioni che le
implementazioni usando il meccanismo delle sottoclassi

Il pattern consente di combinare le diverse astrazioni e implementazioni e
di estenderle in modo indipendente
I cambiamenti nell’implementazione di un’astrazione non devono
avere impatto sui client

51
Bridge: applicabilità (1/2)
Non si vuole ricompilare il client a seguito di cambiamenti
nell’implementazione di un’astrazione
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Bridge: applicabilità (2/2)
4. In C++ si vuole nascondere completamente ai client
l’implementazione di un’astrazione
–
La rappresentazione di una classe è visibile nell’interfaccia della
classe stessa
5. Esiste una serie di “generalizzazioni annidate”
6. Condividere una stessa implementazione fra più oggetti
nascondendo la condivisione ai client
52
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
Bridge: struttura
DEE - Politecnico di Bari
client
Abstraction
imp
Implementor
Operation()
OperationImp()
imp->OperationImp();
RefinedAbstraction
53
ConcreteImplementorA
ConcreteImplementorA
OperationImp()
OperationImp()
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Abstraction
•
RefinedAbstraction
•
Implementor
•
ConcreteImplementor
54
Bridge: partecipanti
– Definisce l’interfaccia dell’astrazione
– Mantiene un riferimento a un oggetto di tipo Implementor
– Estende l’interfaccia definita da Abstraction
– Definisce l’interfaccia per le classi che implementano l’astrazione
– Non deve corrispondere esattamente all’interfaccia di Abstraction, ma le due
interfacce possono essere completamente diverse
– Implementor fornisce solo le operazioni di base mentre Abstraction definisce le
operazioni di più alto livello basate sull’uso di quelle di base
– Fornisce l’interfaccia Implementor e definisce la sua realizzazione concreta
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
55
Bridge: esempio
Implementazione dell’astrazione Window in un toolkit per interfacce utente: dovrebbe
consentire di scrivere applicazioni eseguite indifferentemente su piattaforme x e IBM
Presentation Manager:
–
usando l’ereditarietà sarebbe necessario:
–
Il codice del client diventa dipendente dalla piattaforma utilizzata
•
•
definire un nuova sottoclasse per ogni tipologia di finestra
e per ogni nuova piattaforma una nuova sottoclasse di Window per ogni tipologia di finestra
Il pattern bridge consente di introdurre due gerarchie di classi separate per le
astrazioni di window e per le relative implementazioni: tutte le operazioni sulle
sottoclassi di window sono implementate con operazioni astratte dell’interfaccia
WindowImp:
L’approccio consente di disaccoppaire l’astrazione fornita dalle implementazioni
specifiche: realizza un collegamento fra l’astrazione e la sua implementazione
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator: scopo
• Aggiungere dinamicamente responsabilità a un oggetto
• Fornisce un’alternativa flessibile alla definizione di
sottoclassi come strumento per l’estensione delle
funzionalità
56
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Decorator: motivazione
Aggiungere responsabilità a singoli oggetti e non a un’intera classe
– Si può aggiungere responsabilità mediante ereditarietà
– Svantaggio: approccio poco flessibile perché si procede staticamente
•
•
Usare un oggetto contenitore: decorator
Il decorator:
– ha un’interfaccia conforme a quella dell’elemento decorato in modo da rendere
trasparente la sua presenza ai client
– trasferisce le richieste al componente decorato e può svolgere azioni aggiuntive
•
È possibile annidare i decoratori in modo ricorsivo, consentendo l’aggiunta
di un numero illimitato di responsabilità agli oggetti decorati
57
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator: applicabilità
• Il pattern decorator può essere utilizzato nei seguenti casi:
– Si vuole poter aggiungere responsabilità a singoli oggetti
dinamicamente ed in modo trasparente, senza, cioè coinvolgere altri
oggetti
– Si vuole poter togliere responsabilità agli oggetti
– L’estensione attraverso la definizione di sottoclassi non è praticabile:
• A volte è possibile definire un gran numero di estensioni indipendenti, fatto
che porterebbe a un’esplosione nel numero di sottoclassi per supportare
ogni possibile combinazione.
• O la definizione di un classe potrebbe essere nascosta, oppure non
disponibile per la creazione di sottoclassi
58
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator: struttura
Component
Operation()
ConcreteComponent
Decorator
Operation()
Operation()
ConcreteDecoratorA
Operation()
addedState
59
component
Component->Operation()
ConcreteDecoratorB
Operation()
AddedBehavior()
Ingegneria del software
Decorator::Operation()
AddedBehavior();
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator: partecipanti
• Component
– Definisce l’interfaccia comune per gli oggetti ai quali possono essere
aggiunte responsabilità dinamicamente
• ConcreteComponent
– Definisce un oggetto al quale possono essere aggiunte responsabilità
ulteriori
• Decorator
– Mantiene un riferimento a un oggetto Component e definisce
un’interfaccia conforme all’interfaccia di Component
• ConcreteDecorator
– Aggiunge responsabilità al componente
60
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator: esempio
• Un ambiente per la realizzazione di interface utente dovrebbe
consentire di aggiungere proprietà quali i bordi, o comportamenti
quali lo scorrimento a ogni singolo componente dell’interfaccia
utente:
• Il pattern decorator consente di racchiudere il componente da
decorare in un altro responsabile dell’aggiunta del bordo. Il
decorator ha un’interfaccia conforme a quelle dell’elemento decorato
e trasferisce le richieste al componente decorato
61
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Decorator esempio
VisualCcmponent
Draw()
TextView
Decorator
Draw()
Draw()
ScrollDecorator
Draw()
ScrollTo()
component
BorderDecorator
Draw()
DrawBorder()
scrollPosition
62
Ingegneria del software
component->Draw()
Decorator::draw()
DrawBorder();
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Proxy: scopo
• (detto anche Surrogate)
• Fornire un surrogato o un segnaposto di un altro oggetto
per controllare l’accesso a tale oggetto
63
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Proxy: motivazione
• Controllo dell’accesso di un oggetto: rinviare il costo
della sua creazione e inizializzazione fino a quando
l’oggetto non è effettivamente necessario
64
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Proxy: applicabilità
Il pattern è applicabile:
–
Ogni volta che si ha la necessità di avere un riferimento a un oggetto che sia più versatile o
raffinato di un semplice puntatore:
1. Un proxy remoto fornisce un rappresentante locale per un oggetto in un diverso spazio di
indirizzamento
2. Un proxy virtuale gestisce la creazione su richiesta dui oggetti”costosi”
3. Un proxy di protezione controlla l’accesso a un oggetto: si rivela utilae quando possono essere
definiti diritti di accesso diversi per gli oggetti
4. Un riferimento intelligente sostituisce un puntatore puro a un oggetto, consentendo l’esecuzione di
attività aggiuntive quando si accede all’oggetto referenziato:
–
–
–
65
Conteggio del numero di riferimenti all’oggetto reale per gestire automaticamente la sua distruzione quando non ci
sono più riferimenti attivi (il proxy è chiamato puntatore intelligente)
Caricamento di un oggetto persistente in memoria quando viene referenziato per la prima volta
Verifica che l’oggetto rappresentato sia riservato (locked) quando si richiede di accedervi in modo che nessun altro
oggetto possa modificarlo
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Client
Proxy: struttura
Subject
Request()
…..
RealSubject
Request()
…..
66
realSubject
Proxy
Request()
…..
Ingegneria del software
…
realSubject->Request();
….
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Proxy
–
–
–
–
–
Mantiene un riferimento che consente al Proxy di accedere all’oggetto rappresentato RealSubject.
Un Proxy può accedere a un Subject se le interfacce Subject e RealSubject sono identiche
Fornisce un’interfaccia identica a quella definita da subject, consentendo quindi al proxy di agire come un
sostituto dell’oggetto destinazione
Controlla l’accesso all’oggetto rappresentato e può essere responsabile della sua creazione ed eliminazione
Altre responsabilità dipendono dal tipo di proxy:
•
•
•
proxy remoti: sono responsabili della codifica di una richiesta e dei suoi argomenti nonché dell’invio della richiesta
codificata all’oggetto rappresentato, posto in un diverso spazio di indirizzamento
proxy virtuali: possono memorizzare informazion addizionali sull’oggetto rappresentato allo scopo di posticipare l’accesso
a tale oggetto
proxy di protezione: verificano che il chiamante abbia i permessi di accesso necessari per poter effettuare una richiesta
all’oggetto rappresentato
•
Subject
•
RealSubject
67
Proxy: partecipanti
–
–
Definisce l’interfaccia comune per le classi RealSubject e Proxy, rendendo possibile l’utilizzo del Proxy in
tutte le situazioni in cui è previsto l’utilizzo di RealSubject
Caratterizza l’oggetto reale rappresentato dal proxy
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
•
Proxy: esempio
un editor di documenti che consenta di inserire oggetti grafici all’interno di
un documento: es. immagini di grandi dimensioni, possono introdurre costi
significativi per la loro creazione
Il pattern proxy consente di utilizzare un altro oggetto, un proxy
dell’immagine ( un segnaposto per l’immagine)
– ha lo stesso comportamento dell’immagine vera e propria
– si preoccupa di istanziarla quando richiesto
• il proxy crea l’immagine soltanto quando l’editor di documenti chiede al proxy di
disegnarla sullo schermo invocando l’operazione Draw
• tutte le richieste successive vengono trasferite dal proxy direttamente all’immagine
• Il proxy deve mantenere un riferimento all’immagine dopo la sua creazione
68
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Proxy: esempio
Graphic
DocumentEditor
Draw()
GetExtent()
Store
Load()
…..
Image
Draw()
GetExtent()
Store
Load()
…..
imageImp
extent
69
ImageProxy
image
Draw()
GetExtent()
Store
Load()
…..
filename
extent
Ingegneria del software
if (image==0){
image= LoadImage(fileName)}
Image>Draw()
if (image==0){
return extent;
} else{
return image>GetExtent();
}
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Facade: scopo
• Fornire un’interfaccia unificata per un insieme di
interfacce presenti in un sottosistema
• Definisce un’interfaccia di livello più alto che rende il
sottosistema più semplice da utilizzare
70
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Esame dei pattern strutturali
• Similarità fra i pattern esaminati (partecipanti e
collaborazioni)
• I pattern strutturali si basano sullo stesso insieme
ristretto di meccanismi messi a disposizione dai linguaggi
di programmazione per strutturare il codice e gli
oggetti:ereditarietà singola e multipla per i pattern basati
su classi e composizione per quelli basati su oggetti
71
Ingegneria del software
Marina
Mongiello
Corso di Laurea Triennale in Ingegneria Informatica
Corso di Sistemi Informativi
A. A. 2004 - 2005
Pattern comportamentali
Observer
Strategy
72
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Si occupano di algoritmi e dell’assegnamento di responsabilità tra
oggetti collaboranti
• Oltre a pattern di classi e oggetti descrivono anche pattern di
comunicazione fra oggetti
• Caratterizzano flussi difficili da seguire durante l’esecuzione
• Spostano l’attenzione dal flusso di controllo e si focalizzano sul
modo in cui gli oggetti sono interconnessi tra loro.
73
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Basati su classi:
– Utilizzano l’ereditarietà per distribuire responsabilità e comportamento
fra oggetti diversi
• Basati su oggetti:
– Usano la composizione degli oggetti al posto dell’ereditarietà
– Descrivono (alcuni) come un gruppo di oggetti cooperanti possa
realizzare funzionalità impossibili per un oggetto singolo
– Descrivono come i singoli oggetti si riferiscono l’uno all’altro:
• mantenere riferimenti espliciti agli altri oggetti aumenterebbe notevolmente
l’accoppiamento
74
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Observer: scopo
• Detto anche Dependents, Publish-Subscribe
• Definire una dipendenza uno a molti fra oggetti, in modo
tale che se un oggetto cambia il suo stato, tutti gli
oggetti dipendenti da questo siano notificati e aggiornati
automaticamente
75
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Observer: motivazione
• Il partizionamento di un sistema in insiemi di classi
collaboranti comporta la necessità di mantenere un alto
livello di consistenza tra le classi correlate.
• La consistenza non deve essere ottenuta a scapito
dell’accoppiamento che deve rimanere basso
76
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Observer: applicabilità
• Il pattern Observer può essere usato nei seguenti casi:
– Un’astrazione presenta due aspetti, di cui uno dipendente dall’altro.
• Incapsulando questi aspetti in due oggetti separati è possibile riusarli
indipendentemente
– Una modifica a un oggetto richiede modifiche ad altri oggetti che
dipendono da questo, ma in generale non si conosce il numero degli
oggetti
– Un oggetto ha bisogno di notificare ad altri oggetti senza conoscerne
l’identità precisa: si vuole mantenere un alto livello di disaccoppiamento
77
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
Observer: struttura
DEE - Politecnico di Bari
observers
Subject
Observer
Attach(Observer)
Detach(observer)
Notify()
Update()
for all in observers{
o->Update()}
ConcreteObserver
subject
ConcreteSubject
GetState()
SetState()
return subjectState
Update()
ObserverState=
Subject->getState()
observerState
subectState
78
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Subject
•
Observer
•
ConcreteSubject
•
ConcreteObserver
Observer: partecipanti
– Conosce i propri Observer. Un numero qualsiasi di oggetti Observer può
osservare un soggetto
– Fornisce un’interfaccia per associare e dissociare oggetti Observer
– Fornisce un’interfaccia di notifica per gli oggetti a cui devono essere notificati i
cambiamenti nel subject
– Contiene lo stato a cui gli oggetti concreteObserver sono interessati
– Memorizza un riferimento a un oggettoConcreteSubject
– Contiene informazioni che devono essere constantemente sincronizzate con lo
stato del subject
– Implementa l’interfaccia di notifica di Observer per mantenere il proprio stato
consistente con quello del subject
79
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Observer: pattern correlati
• Mediator: incapsulando una semantica d’aggiornamento
complessa, ChangeManager svolge il ruolo di Mediato fra
soggetto e osservatori
• Singleton: ChangeManager può usare il pattern Singleton
per rendersi unico e globalmente accessibile
80
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Strategy: scopo
• Definire una famiglia di algoritmi, incapsularli e renderli
intercambiabili. Strategy permette agli algoritmi di
variare indipendentemente dai client che ne fanno uso
– Detto anche: policy
81
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Strategy: motivazione
• Codificare dinamicamente in classi algoritmi che
realizzano le stesse funzionalità
• È possibile definire delle classi che incapsulano svariati
algoritmi mediante il pattern strategy: l’algoritmo
incapsulato è chiamato strategy
82
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
•
Strategy: applicabilità
È opportuno usare il pattern strategy nei seguenti casi:
– Molte classi correlate differiscono fra loro solo per il comportamento.
• Strategy fornisce un modo per configurare una classe con un comportamento scelto fra
tanti
– Sono necessarie più varianti di un algoritmo.
• Per esempio, è possibile definire più algoritmi con bilanciamenti diversi fra occupazione
di memoria, velocità di esecuzione, ecc.
– il pattern strategy può essere utilizzato quando queste varianti sono implementate sotto forma
di gerarchia di classi di algoritmi
– Un algoritmo usa una struttura dati che non dovrebbe essere resa nota ai client.
– Il pattern strategy può essere usato per evitare di esporre strutture dati complesse e specifiche
dell’algoritmo
– Una classe definisce molti comportamenti che compaiono all’interno di scelte
condizionali multiple. Al posto di molte scelte condizionali, si suggerisce di
spostare i blocchi di codice correlati in una classe strategy dedicata
83
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
84
Strategy: struttura
Context
Strategy
ContextInterface()
ContextInterface()
ConcreteStrategyA
ConcreteStrategyB
ConcreteStrategyC
AlgorithmInterface()
AlgorithmInterface()
AlgorithmInterface()
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Strategy: partecipanti
• Strategy (compositor)
– Dichiara un’interfaccia comune a tutti gli algoritmi supportati. Context
usa quest’interfaccia per invocare l’algoritmo definito da un
ConcreteStrategy
• ConcreteStartegy (Simplecompositor, TextCompositor,
Arraycompositor)
– Implementa l’algoritmo usando l’interfaccia Strategy
• Context (Composition)
– È configurato con un oggetto ConcreteStrategy
– Contiene un riferimento a un oggetto Strategy
– Può definire un’interfaccia che permetta a Strategy di accedere alla sua
struttura dati
85
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Strategy: collaborazioni
• Strategy e Context collaborano per implementare l’algoritmo voluto:
• Context può passare tutti i dati necessari dall’algoritmo a Strategy quando
viene invocato l’algoritmo.
• Oppure Context può passare se stesso come parametro ai metodi di
Strategy.
• Ciò permette a Strategy di invocare i metodi appropriati su Context
• Context inoltra le richieste dai propri client verso Strategy.
• I client di solito creano e passano un oggetto ConcreteStrategy al contesto
(per inizializzarlo);
– da quel momento i client interagiranno solo con context.
• Spesso il client può scegliere l’oggetto ConcreteStrategy da una famiglia di
sottoclassi concrete di Strategy
86
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Strategy: conseguenze
•
•
•
•
•
•
•
Famiglie di algoritmi correlati
Un’alternativa all’ereditarietà
Le strategie eliminano i blocchi condizionali
Scelta dell’implementazione
I client devono conoscere le diverse Strategy disponibili
Collaborazioni fra Strategy e Context dispendiosa
Aumento del numero di oggetti
87
Ingegneria del software
Marina
Mongiello
Corso di Laurea Triennale in Ingegneria Informatica
Corso di Sistemi Informativi
A. A. 2004 - 2005
Pattern creazionali
88
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Forniscono un’astrazione del processo di istanziazione
degli oggetti
• Aiutano a rendere un sistema indipendente dalla
modalità di creazione, composizione e rappresentazione
degli oggetti utilizzati
89
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Basati su classi: utilizza l’ereditarietà per scegliere le
particolari classe da istanziare
• Basati su oggetti: delega l’istanziazione a un altro
oggetto
90
Ingegneria del software
Marina
Mongiello
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche
• Capacità di incapsulare la conoscenza delle classi
concrete utilizzate nel sistema
• Capacità di nascondere le modalità di creazione e
composizione di tali classi
91
Ingegneria del software
Marina
Mongiello