Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005...

Corso di Laurea Triennale in Ingegneria Corso di Laurea Triennale in Ingegneria InformaticaInformatica Corso di Sistemi InformativiCorso di Sistemi Informativi

A. A. 2004 - 2005A. A. 2004 - 2005

Marina MoMarina Mongiellongiello

Ingegneria del softwareIngegneria del software11

Design patternDesign pattern

Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari



Scopo Scopo

• Usare soluzioni già pronte (Riuso)• Organizzare l’esperienza nella progettazione di

software a oggetti sotto forma di design pattern




Definizione Definizione

• Secondo Gamma [1994] un pattern è composto da quattro elementi:– Un nome– Il problema– La soluzione– Le conseguenze




Il nomeIl 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




Il problema 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




La soluzione 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




Le conseguenzeLe 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




Perché usare i design pattern Perché usare i design pattern

1. Riuso2. Esperienza dello sviluppatore3. Innovazione4. Integrazione 5. Comunicazione




1: Riuso 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)




2: Esperienza dello sviluppatore2: 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.




3: Innovazione 3: Innovazione

Le innovazioni tecniche possono essere diffuse con successo.




4: Integrazione 4: Integrazione

Le tecniche più sperimentate possono essere integrate senza rischi con le conquiste tecniche assolutamente nuove, non ancora sufficientemente verificate




5: Documentazione 5: Documentazione

I pattern costruiscono un modo ben documentato di diffondere la documentazione di progetto




6: Comunicazione 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




Caratteristiche dei pattern Caratteristiche dei pattern

• Sono generali e astratti• Descrivono piccole unità il che li porta ad avere

una elevata flessibilità




Tipi di pattern Tipi di pattern

• Esistono tipologie di pattern che si occupano di risolvere problemi di natura diversa:– Suddivisione dei compiti in un sistema– Cooperazione tra oggetti in un sistema– Pattern per la struttura di interi sistemi– Ecc.




Pattern nella programmazione Pattern nella programmazione orientata agli oggetti 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




Caratteristiche dei design patternCaratteristiche 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




Scopo dei patternScopo 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à




Raggio d’azioneRaggio 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




Creazionali Creazionali

• Abstract factory• Builder• Factory method• Prototype• Singleton




Strutturali Strutturali

• Adapter• Bridge• Composite• Decorator • Facade• Flyweight• Proxy




Comportamentali Comportamentali

• Chain of responsibility• Command • Interpreter• Iterator• Mediator• Memento • Observer• State• Strategy• Template method• Visitor




Catalogo dei patternCatalogo dei pattern

Scopo

Creazionale Strutturale Comportamentale

Raggio d’azione Classi Factory method Adapter Interpreter Template Method

Oggetti Abstarct factoryBuilderPrototypeSingleton

AdapterBridgeCompositeDecoratorFacadeFlyweightProxy

Chain of responsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor


A. A. 2004 - 2005A. A. 2004 - 2005



Pattern strutturaliPattern strutturali

AdapterBridge

DecoratorProxy

FacadeFlyweight




Caratteristiche 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




Adapter (o Wrapper) : scopoAdapter (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.




Adapter: motivazioneAdapter: 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




Adapter: esempioAdapter: esempio

• Un editor che consenta all’utente di disegnare e comporre elementi grafici (linee, poligoni, testo, ecc) per ottenere disegni e diagrammi




(Adapter ) Osservazioni (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




(Adapter) Problema/soluzione(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)




(Adapter) Soluzione adottata(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:– Pattern adapter basato su oggetti

• Classe TextShape: adapter




Adapter (Esempio)Adapter (Esempio)

DrawingEditor Shape TextView

Line TextShape

return->GetExtent()

BoundingBox()CreateManipulator()

GetExtent()



return new TextManipulator

text




(Adapter) Osservazioni (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.




(Adapter) Vantaggi (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)




Adater: applicabilità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




Adapter: struttura (classi)Adapter: struttura (classi)

Client Target Adaptee

Adapter

SpecificRequest()

Request() SpecificRequest()

Request()

• Una classe adapter utilizza l’ereditarietà multipla per adattare un’interfaccia a un’altra

(implementation)




Adapter: struttura (oggetti)Adapter: struttura (oggetti)

Client Target Adaptee

Adapter

adaptee->SpecificRequest()

Request() SpecificRequest()

Request()

• Un oggetto adapter si basa invece sulla composizione di oggetti

adaptee




Adapter: partecipanti 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




ImplementazioneImplementazione

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




Implementazione (class pattern)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;

};




ImplementazioneImplementazione

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);

}




Implementazione 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);

}




Implementazione (object pattern)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;

};





• 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();

}





• 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




Adapter: pattern correlatiAdapter: pattern correlati

• Bridge• Decorator• Proxy




BridgeBridge

• 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




Bridge: scopoBridge: scopo

• (Detto anche Handle/Body)• Disaccoppia un’astrazione dalla sua

implementazione in modo che le due possano variare indipendentemente




Bridge: motivazioneBridge: 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




Bridge: applicabilità (1/2)Bridge: applicabilità (1/2)

• Il pattern bridge può essere usato nei seguenti casi:1. Evitare un legame permanente tra un’astrazione e la sua

implementazione (se ad. L’implementazione deve essere selezionata o modificata

durante l’esecuzione)

2. 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

3. I cambiamenti nell’implementazione di un’astrazione non devono avere impatto sui client Non si vuole ricompilare il client a seguito di cambiamenti

nell’implementazione di un’astrazione




Bridge: applicabilità (2/2)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




Bridge: struttura Bridge: struttura

client

Abstraction

Operation()

RefinedAbstraction

Implementor

OperationImp()

ConcreteImplementorA

OperationImp()

ConcreteImplementorA

OperationImp()

imp->OperationImp();

imp




Bridge: partecipanti Bridge: partecipanti

• Abstraction– Definisce l’interfaccia dell’astrazione– Mantiene un riferimento a un oggetto di tipo Implementor

• RefinedAbstraction– Estende l’interfaccia definita da Abstraction

• Implementor– 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

• ConcreteImplementor– Fornisce l’interfaccia Implementor e definisce la sua realizzazione

concreta




Bridge: esempioBridge: 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:• 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 codice del client diventa dipendente dalla piattaforma utilizzata

• 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




Decorator: scopoDecorator: scopo

• Aggiungere dinamicamente responsabilità a un oggetto

• Fornisce un’alternativa flessibile alla definizione di sottoclassi come strumento per l’estensione delle funzionalità




Decorator: motivazioneDecorator: 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




Decorator: applicabilità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




Decorator: strutturaDecorator: struttura

Component

Operation()

ConcreteComponent

Operation()

Decorator

Operation()

ConcreteDecoratorA

Operation()

ConcreteDecoratorB

Operation()

AddedBehavior() addedState

Component->Operation()

Decorator::Operation()AddedBehavior();

component




Decorator: partecipantiDecorator: 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




Decorator: esempioDecorator: 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




Decorator esempioDecorator esempio

VisualCcmponent

Draw()

TextView

Draw()

Decorator

Draw()

ScrollDecorator

Draw() ScrollTo()

BorderDecorator

Draw()

DrawBorder() scrollPosition

component->Draw()

Decorator::draw()DrawBorder();

component




Proxy: scopoProxy: scopo

• (detto anche Surrogate)• Fornire un surrogato o un segnaposto di un altro

oggetto per controllare l’accesso a tale oggetto




Proxy: motivazione Proxy: motivazione

• Controllo dell’accesso di un oggetto: rinviare il costo della sua creazione e inizializzazione fino a quando l’oggetto non è effettivamente necessario




Proxy: applicabilità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 indirizzamento2. 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 oggetti4. Un riferimento intelligente sostituisce un puntatore puro a un oggetto, consentendo

l’esecuzione di attività aggiuntive quando si accede all’oggetto referenziato:– 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




Proxy: strutturaProxy: struttura

Client Subject Request()…..

RealSubject Request()…..

ProxyRequest()…..

realSubject

…realSubject->Request();….




Proxy: partecipantiProxy: partecipanti

• 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 – 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• RealSubject

– Caratterizza l’oggetto reale rappresentato dal proxy




Proxy: esempioProxy: 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




Proxy: esempioProxy: esempio

DocumentEditor Graphic

Draw()GetExtent()StoreLoad()…..

Image ImageProxy

image

if (image==0){image= LoadImage(fileName)}Image>Draw()Draw()

GetExtent()StoreLoad()…..

Draw()GetExtent()StoreLoad()…..

imageImpextent

filenameextent

if (image==0){return extent;} else{return image>GetExtent();}




Facade: scopoFacade: 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




Esame dei pattern strutturaliEsame 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


A. A. 2004 - 2005A. A. 2004 - 2005



Pattern comportamentaliPattern comportamentali

ObserverStrategy





• 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.





• 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




Observer: scopoObserver: 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




Observer: motivazioneObserver: 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




Observer: applicabilità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




Observer: strutturaObserver: struttura

Attach(Observer)Detach(observer)

Notify()

Subject

GetState()SetState()

ConcreteSubject Update()

ConcreteObserver

subectState

for all in observers{ o->Update()}

return subjectState

ObserverState=Subject->getState()

Update()

Observer

observerState

subject

observers




Observer: partecipantiObserver: partecipanti

• Subject– Conosce i propri Observer. Un numero qualsiasi di oggetti Observer

può osservare un soggetto – Fornisce un’interfaccia per associare e dissociare oggetti Observer

• Observer – Fornisce un’interfaccia di notifica per gli oggetti a cui devono essere

notificati i cambiamenti nel subject• ConcreteSubject

– Contiene lo stato a cui gli oggetti concreteObserver sono interessati• ConcreteObserver

– 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




Observer: pattern correlatiObserver: 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




Strategy: scopoStrategy: 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




Strategy: motivazioneStrategy: 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




Strategy: applicabilità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




Strategy: strutturaStrategy: struttura

Context

ContextInterface()

Strategy

ContextInterface()

ConcreteStrategyA

AlgorithmInterface()

ConcreteStrategyB


ConcreteStrategyC





Strategy: partecipantiStrategy: 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




Strategy: collaborazioniStrategy: 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




Strategy: conseguenzeStrategy: 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


A. A. 2004 - 2005A. A. 2004 - 2005



Pattern creazionaliPattern creazionali





• 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





• Basati su classi: utilizza l’ereditarietà per scegliere le particolari classe da istanziare

• Basati su oggetti: delega l’istanziazione a un altro oggetto





• Capacità di incapsulare la conoscenza delle classi concrete utilizzate nel sistema

• Capacità di nascondere le modalità di creazione e composizione di tali classi

Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005...

Documents

Transcript of Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005...