Design Patterns

Riferimenti
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,
“Design Patterns: Elements of Reusable Object Oriented Software“.

• http://www.dofactory.com/Patterns/Patterns.aspx
• www.lta.disco.unimib.it/didattica/IngSw/slide/Design
Patterns/Presentazione Design Patterns-03.ppt
• http://www.elet.polimi.it/upload/picco/Teaching/softeng/slides/Design
Patterns-Lucidi.pdf
• Marcello Esposito, Elementi per la progettazione di. Software
Object-Oriented riusabile ed estensibile,
http://www.grid.unina.it/Didattica/P1/tlc0405/slides/11%20-
%20DesignPatterns.pdf

• DPA Toolkit, http://dpatoolkit.sourceforge.net/

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 2

 Storia
• Introdotti dall’architetto (di edifici, non di
software) Christopher Alexander.
– “Ogni pattern descrive un problema che si presenta
frequentemente nel nostro ambiente, e quindi
descrive il nucleo della soluzione così che si possa
impiegare tale soluzione milioni di volte, senza
peraltro produrre due volte la stessa realizzazione.”
• Il principio è ugualmente valido, anche se riferito
ad oggetti, classi ed interfacce piuttosto che ad
elementi architettonici come muri, archi,pilastri,
ecc.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 3

 Pattern
• Un Pattern
– individua un’IDEA, uno schema GENERALE E RIUSABILE
• schema di problema,
• schema di soluzione, etc.
– non è paragonabile ad un componente riusabile perchè
• non è un “oggetto” fisico
• non può essere usato così come è stato definito, ma deve essere
contestualizzato all’interno del particolare problema applicativo
– due istanze/contestualizzazioni di uno stesso pattern (ad
esempio in problemi diversi) tipicamente sono diverse proprio
per la contestualizzazione in domini differenti

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 4

 Scopo dei Patterns
• Scopo dei pattern
– Catturare l’esperienza e la “saggezza” degli esperti
– Evitare di reinventare ogni volta le stesse cose

• Cosa fornisce un design pattern al progettista software?

– Una soluzione codificata e consolidata per un problema
ricorrente
– Un’astrazione di granularità e livello di astrazione più elevati di
una classe
– Un supporto alla comunicazione delle caratteristiche del progetto
– Un modo per progettare software con caratteristiche predefinite
– Un supporto alla progettazione di sistemi complessi

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 5

 Definizione
• Definizione:
Ogni pattern descrive un problema specifico che ricorre
più volte e descrive il nucleo della soluzione a quel
problema, in modo da poter utilizzare tale soluzione un
milione di volte, senza mai farlo allo stesso modo.

• Abbastanza astratti
– in modo da poter essere condivisi da progettisti con punti di vista
diversi

• Non complessi nè domain-specific

– non rivolti alla specifica applicazione ma riusabili in parti di
applicazioni diverse

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 6

 Caratteristiche
• Un Design Pattern
– Nomina
– Astrae
– Identifica
gli aspetti chiave di una struttura comune di design che la rendono
utile nel contesto del riuso in ambito object-oriented

• Un Design Pattern identifica

– le classi (e le istanze) partecipanti
– le associazioni ed i ruoli
– le modalità di collaborazione tra le classi coinvolte
– la distribuzione delle responsabilità nella soluzione del
particolare problema di design considerato

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 7

 Tipologie di pattern
• Esistono diverse tipologie di pattern, che si
differenziano principalmente per la scala ed il
livello di astrazione:
– Architectural Pattern
• Utili per strutturare un sistema in sottosistemi
– Design Pattern
• Operano essenzialmente a livello di un singolo sottosistema
evidenziando le caratteristiche delle classi coinvolte e delle
associazioni tra le classi
– Idioms
• Utili per l’implementazione di specifici aspetti di design in un
particolare linguaggio di programmazione

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 8

 Come sono fatti i Design Patterns
• Un pattern è formato da quattro elementi essenziali:

1. Il nome del pattern, è utile per descrivere la sua funzionalità in una o due
parole.

2. Il problema nel quale il pattern è applicabile. Spiega il problema e il

contesto, a volte descrive dei problemi specifici del design mentre a volte
può descrivere strutture di classi e oggetti. Può anche includere una lista
di condizioni che devono essere soddisfatte precedentemente perché il
pattern possa essere applicato.

3. La soluzione che descrive in modo astratto come il pattern risolve il

problema. Descrive gli elementi che compongono il design, le loro
responsabilità e le collaborazioni.

4. Le conseguenze portate dall'applicazione del pattern. Spesso sono

tralasciate ma sono importanti per poter valutare i costi-benefici
dell'utilizzo del pattern.
P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 9
 Esempio Descrizione DP
• Nome e classificazione del pattern
• Sinonimi: altri nomi del pattern
• Scopo: cosa fa il pattern? a cosa serve?
• Motivazione: scenario che illustra un design problem
• Applicabilità: situazioni in cui si applica il pattern
• Struttura: rappresentazione delle classi in stile OMT
• Partecipanti: classi e oggetti inclusi nel pattern
• Collaborazioni: come i partecipanti collaborano
• Conseguenze: come consegue i suoi obiettivi il pattern?
• Implementazione: che tecniche di codifica sono necessarie?
• Codice di esempio: scritto in un linguaggio a oggetti
• Usi noti: esempi d’applicazione del pattern in sistemi reali
• Pattern correlati: con quali altri pattern si dovrebbe usare?

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 10

 Categorie di Pattern
• Un esempio di catalogo DP è presente nel libro Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides, “Design Patterns: Elements of
Reusable Object Oriented Software“.
– I pattern qui descritti sono spesso denominati pattern GoF (Gang of Four), per
ricordarne i 4 autori

• Esistono diverse categorie di pattern, che descrivono la funzione

(purpose) e il dominio (scope) del pattern.

• Funzione (purpose), ovvero cosa fa il pattern:

– Creazionali (creational): forniscono meccanismi per la creazione di
oggetti
– Strutturali (structural): gestiscono la separazione tra interfaccia e
implementazione e le modalità di composizione tra oggetti
– Comportamentali (behavioral): consentono la modifica del
comportamento degli oggetti minimizzando le necessità di cambiare il
codice

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 11

 Categorie di Pattern
• Dominio (scope), indica se il pattern si applica a
classi o oggetti:
– Class pattern
• Si focalizzano su relazioni fra classi e sottoclassi.
Tipicamente si riferiscono a situazioni statiche (Es. relazioni
espresse attraverso l’ereditarietà), ovvero riguardano il
compile-time.
– Object pattern
• Si focalizzano su oggetti (istanze) e loro relazioni.
Tipicamente si riferiscono a situazioni dinamiche (le relazioni
tra oggetti possono ovviamente cambiare a run-time).

La differenza è comunque molto sfumata

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 12

 DPA Toolkit
• Free software che permette di:
– Disegnare Class Diagrams;
– Disegnare Class Diagrams contenenti Design
Patterns;
– Generare codice sorgente in C++, C#, Java, VB.NET
conforme al class diagram disegnato;
– Ricostruire diagrammi delle classi a partire dal codice,
riconoscendo eventuali istanziazioni di design pattern
• Scaricabile da http://dpatoolkit.sourceforge.net/

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 13

 Categoria Creational

• Questa categoria raccoglie i pattern che forniscono

un'astrazione per il processo di istanziazione.

• Questi pattern permettono di rendere un sistema

indipendente da come sono creati, rappresentati e
composti gli oggetti al suo interno.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 14

 Categoria Creational

Design Descrizione
Patterns
Separa la costruzione di un oggetto complesso dalla sua
Builder rappresentazione in modo da poter usare lo stesso processo di
costruzione per altre rappresentazioni
Abstract Provvede ad un interfaccia per creare famiglie di oggetti in
Factory relazione senza specificare le loro classi concrete
Factory Method Definisce un interfaccia per creare un oggetto ma lascia
decidere alle sottoclassi quale classe istanziare
Prototype Specifica il tipo di oggetto da creare usando un istanza
prototipo e crea nuovi oggetti copiando questo prototipo
Singleton Assicura che la classe abbia una sola istanza e provvede un
modo di accesso
P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 15
 DP: Singleton (Creazionale)
• Nome: Singleton

• Scopo : Costruire classi che supportino una e

una sola istanza di oggetto e forniscono un
punto d’accesso globale a tale istanza

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 16

 Esempio
class Singleton { Singleton* Singleton::_instance = 0;
public:
static Singleton* Instance(); Singleton* Singleton::Instance () {
protected: if (_instance == 0) {
Singleton(); _instance = new Singleton;
private: }
static Singleton* _instance; return _instance;
}; }

• Il puntatore _instance è static, quindi persiste al variare degli oggetti

• Il puntatore _instance è private, quindi non può essere modificato dall’esterno
• puntatore _instance è inizializzato staticamente a zero, quindi è sempre interrogabile
• Il costruttore è protetto in modo da poter essere invocato solo da Instance()
• Il puntatore all’oggetto è ottenibile da chiunque chiamando il metodo pubblico
Instance()

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 17

 DP : Abstract Factory
(Creazionale)
• Nome: Abstract Factory

• Sinonimo : Kit

• Scopo : Fornisce un'interfaccia per creare famiglie di oggetti

connessi o dipendenti tra loro, in modo che non ci sia necessità
da parte dei client di specificare i nomi delle classi concrete
all'interno del proprio codice.
In questo modo si permette che un sistema sia indipendente
dall'implementazione degli oggetti concreti e che il client,
attraverso l'interfaccia, utilizzi diverse famiglie di prodotti.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 18

 Abstract Factory: struttura

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 19

 Abstract Factory
• Partecipanti :
• AbstractFactory
– Dichiara l'interfaccia per tutti i costruttori astratti.
• ConcreteFactory
– Implementa i costruttori dei prodotti
• AbstractProduct
– Dichiara l'interfaccia per un tipo di prodotto.
• ConcreteProduct
– Implementa l'interfaccia AbstractProduct e definisce l'oggetto
prodotto che deve essere creato dalla factory concreta
corrispondente.
• Client
– Utilizza solo le interfacce dichiarate da AbstractFactory e
AbstractProduct.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 20

Esempio // The 'AbstractProduct' abstract classes
abstract class Herbivore { }
abstract class Carnivore {
// Codice completo: public abstract void Eat(Herbivore h);
http://www.dofactory.com/Patterns/PatternAbs }
tract.aspx#_self2
// The 'AbstractFactory' abstract class // The 'Product' classes
class Wildebeest : Herbivore {… }
abstract class ContinentFactory {
class Lion : Carnivore {…}
public abstract Herbivore CreateHerbivore(); class Bison : Herbivore { … }
public abstract Carnivore CreateCarnivore(); class Wolf : Carnivore { … }
}
// The 'Client' class
class AnimalWorld {
// The 'ConcreteFactory' classes
private Herbivore _herbivore;
class AfricaFactory : ContinentFactory { private Carnivore _carnivore;
public override Herbivore CreateHerbivore() { // Constructor
return new Wildebeest(); public AnimalWorld(ContinentFactory factory) {
} _carnivore = factory.CreateCarnivore();
_herbivore = factory.CreateHerbivore();
public override Carnivore CreateCarnivore() {
}
return new Lion(); }
} }
} public static void Main() {
class AmericaFactory : ContinentFactory { ContinentFactory africa = new AfricaFactory();
AnimalWorld world = new AnimalWorld(africa);
…P.Tramontana – 2009 – Ingegneria del Software - Design Patterns
… 21
 Categoria Structural
• I pattern di questa categoria sono dedicati alla
composizione di classi e oggetti per creare delle strutture
più grandi.

• È possibile creare delle classi che ereditano da più classi

per consentire di utilizzare proprietà di più superclassi
indipendenti.

• Ad esempio permettono di far funzionare insieme delle

librerie indipendenti.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 22

 Categoria Structural
Design Patterns Descrizione
Converte l’interfaccia di una classe in un’altra permettendo a due
Adapter classi di lavorare assieme anche se hanno interfacce diverse.

Bridge Disaccoppia un’astrazione dalla sua implementazione in modo che

possano variare in modo indipendente.

Composite Compone oggetti in strutture ad albero per implementare delle

composizioni ricorsive

Decorator Aggiunge nuove responsabilità ad un oggetto in modo dinamico, è un

alternativa alle sottoclassi per estendere le funzionalità

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 23

 Categoria Structural

Design Patterns Descrizione

Facade Provvede un interfaccia unificata per le interfacce di un sottosistema
in modo da rendere più facile il loro utilizzo

Proxy Provvede un surrogato di un oggetto per controllarne gli accessi

Flyweight Usa la condivisione per supportare in modo efficiente un gran

numero di oggetti con fine granularità

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 24

 DP : Adapter (Strutturale)
• Nome: Adapter

• Sinonimo : Wrapper

• Scopo : Converte l’interfaccia di una classe in un’altra interfaccia, attesa

da un cliente (quindi permette la cooperazione di classi che altrimenti
avrebbero interfacce incompatibili)

• Motivazione : In alcune circostanze non si potrebbe utilizzare una

classe già esistente e collaudata solo perché quest’ultima non comunica
con l’interfaccia richiesta dalla nostra applicazione

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 25

 Adapter
• Partecipanti :
• Target : definisce l’interfaccia specializzata usata
dal client
• Client : collabora con oggetti conformi
all’interfaccia target
• Adaptee : definisce un ‘interfaccia che deve essere
resa conforme
• Adapter : adatta l’interfaccia di adaptee
all’interfaccia Target

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 26

 DP : Adapter
• Struttura :

Target Adaptee
Client

+Request() +SpecificRequest()

Adapter

+Request() {SpecificRequest();}

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 27

 DP : Adapter
• Struttura ( alternativa):

Target Adaptee
Client
Request() SpecificRequest()

adaptee
Adapter Adaptee. SpecificReques t()

Request()

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 28

 DP : Adapter
• Esempio: un editor grafico usa una classe Shape per
editare e visualizzare gli oggetti grafici.

• Il progettista possiede una classe riusabile TextView

per editare e visualizzare testo.

• Purtroppo TextView non sa nulla di Shape.

• Possiamo però definire una nuova classe TextShape

che incapsuli TextView e adatti la sua interfaccia a
quella di Shape.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 29

 DP : Adapter
• Esempio concreto di adattatore

Target Adaptee

Adapter

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 30

 DP : Adapter

• Applicabilità:
Adapter puo essere utilizzato :
1. Se si vuole utilizzare una classe esistente la cui interfaccia
sia incompatibile
2. Se si vuole creare una classe (riusabile) che dovrà
collaborare con classi non prevedibili al momento della sua
creazione
3. Se si vuole riusare un insieme di sottoclassi esistenti, ma è
scomodo adattare l’interfaccia creando una sottoclasse per
ciascuna: meglio creare un adattatore per la classe
genitore

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 31

 Esempio codice C++
// Target
class Shape
{
public:
Shape();
virtual void BoundingBox(Point& bottomLeft, Point& topRight) const;
virtual Manipulator* CreateManipulator() Const;
};

// Adaptee
class TextView
{
public:
TextView();
void GetOrigin(Coord& x, Coord& y) const;
void GetExtent(Coord& width, Coord& height) const;
virtual bool IsEmpty() const;
};
P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 32
 Esempio codice C++
// Adapter
class TextShape: public Shape, private TextView
{ //eredita privatamente da TextView, perché non vuole inoltrare l’ereditarietà
public:
TextShape();
void BoundingBox(Point& bottomLeft, Point& topRight) const;
virtual bool IsEmpty() const;
Manipulator* CreateManipulator() Const;
};

// Implementazione TextShape::BoundingBox
void TextShape::BoundingBox(Point& bottomLeft, Point& topRight) const
{
Coord bottom, left, width, height;
GetOrigin(bottom,left); // metodi ereditati da TextView
GetExtent(width,height);
bottomLeft=Point(bottom,left);
topRight=Point(bottom+height,left+width)
};
P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 33
 Esempio
• Nella realizzazione di un software object oriented per il mercato statunitense si
vuole realizzare una classe Health che fornisca, tra l’altro, l’indice di massa
corporeo (IMC) di una persona, secondo l’interfaccia riportata qui sotto:
Health
+IMC
+Evaluate_IMC(Weight, Height)

Non conoscendo l’algoritmo che permette di calcolare tale indice, si decide di

riutilizzare una classe IMC, presa da un software realizzato per il mercato italiano
che dispone della seguente interfaccia:
IMC

Calcola(PesoKg : Double, AltezzaMetri : Double) : Double

Sono note le seguenti relazioni tra unità di misura:

1 libbra è pari a 0,453 kilogrammi 1 pollice è pari a 0,0254 metri

- Si progetti il class diagram a livello di dettaglio che sia in grado di risolvere il problema
proposto svincolando il programmatore della classe Health dalla conoscenza
dell’interfaccia e dell’implementazione della classe IMC, utilizzando il design pattern
Adapter.
P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 34
 Soluzione possibile

{imc.Calcola(PesoKg,AltezzaM)}

Health
Target_
+IMC Adaptee_

+Evaluate_IMC(Weight, Height) +Evaluate(WPound, HInch)

+CalcolaIMC(PesoKg, AltezzaM)

Adapter_
IMC
{CalcolaIMC(WPound/0.453,HInch/0.0254} +Evaluate(WPound, HInch)
+Calcola(PesoKg, AltezzaM)

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 35

 Design Pattern Composite
• Scopo Comporre oggetti in strutture ad albero in
grado di rappresentare gerarchie tutto-parti.
Si vuole che i client trattino allo stesso modo sia
oggetti composti che oggetti individuali

Graphic

Draw()
Add(g : Graphic)
Remove(g : Graphic)
GetChild(i : Integer)
+graphic s

Line Rectangle Text Picture

for all g in graphics g.Draw()
Draw() Draw() Draw() Draw()
Add(g : Graphic)
Remove(g : Graphic) add g to list of graphics
GetChild(i : Integer)

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 36

 Composite
<<Abstract>>
Component

Client Add(Component)
Remove(Component)
GetChild()
Operation()

Composite
Leaf
Add()
Operation() Remove()
GetChild()

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 37

 Design Pattern Composite
Partecipants (classi e oggetti)
• Component (Graphic) dichiara l’interfaccia degli oggetti e il comportamento
di default, dichiara un’interfaccia per l‘accesso e la gestione dei suoi
componenti figli

• Leaf (Line, Rectangle) rappresenta gli oggetti componenti senza figli e il

loro comportamento

• Composite (Picture) definisce il comportamento dei componenti con i figli,

memorizza i componenti figli, implementa le operazione correlate ai figli
definite dall’interfaccia Component

• Client manipola gli oggetti della composizione utilizzando l’interfaccia

Componente

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 38

 Design Pattern Composite
I clienti usano l’interfaccia della classe
Component (Graphic)
– se le richieste sono su una foglia verranno
gestite direttamente dalla classe foglia,
– se le richieste sono su una classe composite
(Picture) verranno redirette (in modo nascosto)
sulle classi figlie componenti.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 39

 Considerazioni
• Il pattern Composite
– Consente di definire gerarchie di classi costituite da
oggetti primitivi e compositi.
• Gli oggetti primitivi possono essere composti per formare
oggetti più complessi, che a loro volta potranno essere
composti ricorsivamente.
• In tutti i punti in cui il client si aspetta di utilizzare un oggetto
primitivo, potrà essere indifferentemente utilizzato un oggetto
composito.
– Semplifica il client.
• I client possono trattare strutture composite e singoli oggetti
in modo uniforme.
• I client solitamente non sanno (e non dovrebbero neanche
preoccuparsene) se stanno operando con una foglia o con
un componente composito.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 40

 Composite
• Conseguenze .....
– Semplifica il client: il client puo’ trattare strutture
composte e singoli oggetti in modo uniforme
– Rende piu’ semplice l’aggiunta di nuove tipologie di
componenti (nuove sottoclassi Leaf o Composite
potranno essere utilizzate automaticamente nelle
strutture esistenti e operare con il codice dei client)
– Puo’ rendere il progetto troppo generico per la facile
aggiunta di nuove componenti

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 41

 Esempio in C++
File Component.h File Component.cpp
#ifndef _Component_H #include "Component.h"
#define _Component_H { Component::Component() { }
{ class Component void Component::Add(Component component){}
{ public: void Component::GetChild( int index){ }
Component(); }
void Add (Component component) ;
void GetChild (int index) ;
};
}
#endif

File Composite.h File Composite.cpp

#ifndef _Composite_H #include "Composite.h"
#define _Composite_H { Composite::Composite() { }
{ class Component; //al posto di include, per brevità void Composite::Add( Component component){}
class Composite :public Component void Composite::GetChild( int index){ }
{ Component children; }
public:
Composite();
void Add ( Component component) ;
void GetChild ( int index) ;
};
}
#endif

File Leaf.h File Leaf.cpp

#ifndef _Leaf_H #include "Leaf.h"
#define _Leaf_H { Leaf::Leaf(){ }
{ class Component; //al posto di include, per brevità void Leaf::Add( Component component){ }
class Leaf :public Component void Leaf::GetChild( int index){ }
{ public: }
Leaf();
void Add ( Component component) ;
void GetChild ( int index) ;
};
}
#endif

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 42

 Altro esempio
#include <iostream>
#include <vector>

using namespace std;

class Component { public: virtual void traverse() = 0; };

class Primitive : public Component {

int value;
public:
Primitive( int val ) { value = val; }
void traverse() { cout « value « " "; }
};

class Composite : public Component {

vector<Component*> children;
int value;
public:
Composite( int val ) { value = val; }
void add( Component* c ) { children.push_back( c ); }
void traverse() {
cout « value « " ";
for (int i=0; i < children.size(); i++)
children[i]->traverse();
} };

class Row : public Composite { public: // Due diversi tipi di classi

Row( int val ) : Composite( val ) { } // "container". La maggior parte del
void traverse() { // codice è nella classe base
Composite
cout « "Row";
Composite::traverse();
} };

class Column : public Composite { public:

Column( int val ) : Composite( val ) { }
void traverse() {
cout « "Col";
Composite::traverse();
} };

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 43

 Categoria Behavioral
• Questi pattern sono dedicati all'assegnamento di responsabilità tra
gli oggetti e alla creazione di algoritmi.

• Una caratteristica comune in questi pattern è il supporto per seguire

le comunicazioni che avvengono tra le classi.

• l'utilizzo di questi pattern permette di dedicarsi principalmente alle

connessioni tra oggetti lasciando in disparte la gestione dei flussi di
controllo.

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 44

 Categoria Behavioral
Design Descrizione
Patterns
Chain of Evita l’accoppiamento di chi manda una richiesta con chi la riceve
dando a più oggetti la possibilità di maneggiare la richiesta.
Responsability

Command Incapsula una richiesta in un oggetto in modo da poter eseguire

operazioni che non si potrebbero eseguire.

Interpreter Dato un linguaggio, definisce una rappresentazione per la sua

grammatica ed un interprete per le frasi del linguaggio.

Iterator Fornisce un modo di accesso agli elementi di un oggetto aggregato

in modo sequenziale senza esporre la sua rappresentazione
sottostante
Mediator Definisce un oggetto che incapsula il modo in cui un insieme di
oggetti interagisce in modo da permettere la loro indipendenza

Memento Cattura e porta all'esterno lo stato interno di un oggetto senza

violare l'incapsulazione in modo da ripristinare il suo stato più tardi

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 45

 Categoria Behavioral
Design Patterns Descrizione
Definisce una dipendenza 1:N tra oggetti in modo che se uno cambia
Observer stato gli altri siano aggiornati automaticamente

State Permette ad un oggetto di cambiare il proprio comportamento a

seconda del suo stato interno, come se cambiasse classe di
appartenenza
Strategy Definisce una famiglia di algoritmi, li incapsula ognuno e li rende
intercambiabili in modo da cambiare in modo indipendente dagli
utilizzatori
Template method Definisce lo scheletro di un algoritmo in un'operazione lasciando
definire alcuni passi alle sottoclassi

Visitor Rappresenta un'operazione da fare sugli elementi della struttura di

un oggetto. Lascia definire nuove operazioni senza cambiare classe
degli elementi

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 46

Pattern comportamentali: Observer
• Contesto:
– uno o più oggetti sono interessati ad osservare i cambiamenti di
stato di un soggetto

• Problema:
– Il soggetto deve essere indipendente dal numero e dal tipo degli
osservatori
– Deve essere possibile aggiungere nuovi osservatori durante
l’esecuzione dell’applicazione

• Soluzione:
– inserire nel soggetto delle operazioni che consentono
all’osservatore di dichiarare il proprio interesse per un
cambiamento di stato

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 47

 Observer: la struttura

AbstractSubject
observers 0..n Observer
for all o in observers attach()
o.update() detach() update()
notify()

ConcreteSubject ConcreteObserver
subject ConcreteObserver()
observerSt ate
getState() {subject.attach();}
1
setState() update()

observerState=subject.getState

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 48

 Observer: comportamento
dinamico
: : External
ConcreteObserver ConcreteSubject Source
attach(Observer)

setState( )

update( ) notify( )

getState( )

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 49

 Quando usare l’Observer
• Quando i cambiamenti su un soggetto devono
essere inviati in “broadcast” a tanti oggetti
• Quando oggetti indipendenti dall’applicazione (i
soggetti) devono richiamare oggetti implementati
specificamente per l’applicazione per notificare
un cambiamento nel loro stato interno (i soggetti
non devono conoscere niente riguardo ai loro
osservatori ne’ come funzionano)

P.Tramontana – 2009 – Ingegneria del Software - Design Patterns 50