Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 1 Design pattern.

Presentazione sul tema: "Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 1 Design pattern."— Transcript della presentazione:

1 Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 1 Design pattern

2 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software2 Scopo Usare soluzioni già pronte (Riuso) Organizzare lesperienza nella progettazione di software a oggetti sotto forma di design pattern

3 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software3 Definizione Secondo Gamma [1994] un pattern è composto da quattro elementi: –Un nome –Il problema –La soluzione –Le conseguenze

4 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software4 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

5 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software5 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

6 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software6 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

7 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software7 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 dallinizio si possa valutare lusabilità del pattern

8 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software8 Perché usare i design pattern 1.Riuso 2.Esperienza dello sviluppatore 3.Innovazione 4.Integrazione 5.Comunicazione

9 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software9 1: Riuso I design pattern traggono origine dallesperienza, cosa che facilita essenzialmente il riuso delle conoscenze (al contrario delle teoria astratte che devono essere adattate alle applicazioni concrete)

10 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software10 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.

11 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software11 3: Innovazione Le innovazioni tecniche possono essere diffuse con successo.

12 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software12 4: Integrazione Le tecniche più sperimentate possono essere integrate senza rischi con le conquiste tecniche assolutamente nuove, non ancora sufficientemente verificate

13 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software13 5: Documentazione I pattern costruiscono un modo ben documentato di diffondere la documentazione di progetto

14 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software14 6: Comunicazione Con laiuto 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

15 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software15 Caratteristiche dei pattern Sono generali e astratti Descrivono piccole unità il che li porta ad avere una elevata flessibilità

16 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software16 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.

17 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software17 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

18 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software18 Caratteristiche dei design pattern I design pattern si caratterizzano per –Granularità –Livello dastrazione Criteri di classificazione –Scopo: cosa fa il pattern –Raggio dazione: se si applica a classi o a oggetti

19 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software19 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à

20 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software20 Raggio dazione Class pattern: riguardano le relazioni fra classi e sottoclassi –Espresse attraverso lereditarietà statiche fissate al momento della compilazione Object pattern: riguardano relazioni fra oggetti: –Possono essere cambiate durante lesecuzione, sono dinamiche –Sono i più numerosi

21 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software21 Creazionali Abstract factory Builder Factory method Prototype Singleton

22 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software22 Strutturali Adapter Bridge Composite Decorator Facade Flyweight Proxy

23 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software23 Comportamentali Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor

24 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software24 Catalogo dei pattern Scopo CreazionaleStrutturaleComportamentale Raggio dazioneClassiFactory methodAdapterInterpreter Template Method OggettiAbstarct factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

25 Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 25 Pattern strutturali Adapter Bridge Decorator Proxy Facade Flyweight

26 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software26 Caratteristiche Si occupano delle modalità di composizione di classi e oggetti per formare strutture complesse Basati su classi: –Utilizzano lereditarietà 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 lesecuzione Adapter; Bridge; Decorator; Proxy Composite; Flyweight Facade

27 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software27 Adapter (o Wrapper) : scopo Convertire linterfaccia di una classe in unaltra interfaccia richiesta dal client. Consente a classi diverse di operare insieme quando ciò non sarebbe altrimenti possibile a causa di interfacce incompatibili.

28 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software28 Adapter: motivazione Una classe di supporto progettata con obiettivi di riuso, talvolta può non essere riusabile perché la sua interfaccia non è compatibile con linterfaccia specifica richiesta da unapplicazione

29 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software29 Adapter: esempio Un editor che consenta allutente di disegnare e comporre elementi grafici (linee, poligoni, testo, ecc) per ottenere disegni e diagrammi

30 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software30 (Adapter ) Osservazioni Shape astratta: classe che definisce linterfaccia per gli oggetti grafici Lapplicazione 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

31 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software31 (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 linterfaccia TextView a quella di Shape (Corretta)

32 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software32 (Adapter) Soluzione adottata 1.Ereditare linterfaccia di Shape e limplementazione di TextView: –Pattern adapter basato su classi 2.Comporre unistanza di TextView in una TextShape ed implementare TextShape attraverso linterfaccia di TextView: –Pattern adapter basato su oggetti Classe TextShape: adapter

33 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software33 Adapter (Esempio) DrawingEditorShapeTextView LineTextShape return->GetExtent() BoundingBox() CreateManipulator() GetExtent() BoundingBox() CreateManipulator() BoundingBox() CreateManipulator() return new TextManipulator text

34 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software34 (Adapter) Osservazioni Oggetto adapter Richieste BoundingBox, dichiarate nella classe Shape convertite in richieste GetExtent definite in TextView TextShape adatta TextView allinterfaccia Shape quindi leditor grafico può riusare la classe TextView che altrimenti sarebbe incompatibile.

35 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software35 (Adapter) Vantaggi Ladapter fornisce funzionalità che la classe adattata non è in grado di supportare: –Nellesempio: 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 loperazione CreateManipulator di Shape che ritorna unistanza della sottoclasse appropriata Manipulator. Manipulator è una classe astratta per oggetti che sanno muovere una Shape come risposta a unazione dellutente (es. trascinamento di una figura verso unaltra posizione)

36 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software36 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

37 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software37 Adapter: struttura (classi) ClientTargetAdaptee Adapter SpecificRequest() Request()SpecificRequest() Request() Una classe adapter utilizza lereditarietà multipla per adattare uninterfaccia a unaltra (implementation)

38 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software38 Adapter: struttura (oggetti) ClientTargetAdaptee Adapter adaptee->SpecificRequest() Request()SpecificRequest() Request() Un oggetto adapter si basa invece sulla composizione di oggetti adaptee

39 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software39 Adapter: partecipanti Target (Shape) –Definisce linterfaccia specifica del dominio utilizzata dal client Client /DrawingEditor) –Collabora con oggetti compatibili con linterfaccia Target Adaptee (TextView) –Individua uninterfaccia esistente che deve essere adattata Adapter (TextShape) –Adatta linterfaccia di Adaptee allinterfaccia Target

40 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software40 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

41 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software41 Implementazione (class pattern) La classe adapter utilizza lereditarietà 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; };

42 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software42 Implementazione BoundingBox converte linterfaccia 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); }

43 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software43 Implementazione Loperazione IsEmpty mostra un esempio di trasferimento delle richieste, attività di base nellimplementazione 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); }

44 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software44 Implementazione (object pattern) Loggetto adapter utilizza la composizione tra oggetti per combinare classi con interfacce diverse. Ladattatore 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; };

45 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software45 Implementazione TextShape deve inizializzare il puntatore allistanza di TextView, e lo fa nel costruttore Deve invocare le operazioni sulloggetto TextView ogni volta che viene richiesta una sua operazione Si suppone che il cliente crei loggetto 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(); }

46 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software46 Implementazione Limplementazione 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); } Lutilizzo 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 unistanza della sottoclasse di Textview al costruttore di TextShape

47 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software47 Adapter: pattern correlati Bridge Decorator Proxy

48 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software48 Bridge Ha una struttura simile a quella di un oggetto adapter, ma ha un obiettivo diverso: –Separare uninterfaccia dalla sua implementazione in modo che le due possano variare facilmente e indipendentemente

49 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software49 Bridge: scopo (Detto anche Handle/Body) Disaccoppia unastrazione dalla sua implementazione in modo che le due possano variare indipendentemente

50 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software50 Bridge: motivazione Rendere unastrazione più flessibile: –Se unastrazione può avere più implementazioni possibili, si ricorre allereditarietà: Una classe astratta definisce linterfaccia dellastrazione le sottoclassi la implementano in modi differenti Svantaggio: Tale soluzione è poco flessibile perché lega unimplementazione a unastrazione in modo permanente: –è difficile »Modificare »Estendere »Riusare –astrazioni e implementazioni in modo indipendente

51 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software51 Bridge: applicabilità (1/2) Il pattern bridge può essere usato nei seguenti casi: 1.Evitare un legame permanente tra unastrazione e la sua implementazione (se ad. Limplementazione deve essere selezionata o modificata durante lesecuzione) 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 nellimplementazione di unastrazione non devono avere impatto sui client Non si vuole ricompilare il client a seguito di cambiamenti nellimplementazione di unastrazione

52 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software52 Bridge: applicabilità (2/2) 4.In C++ si vuole nascondere completamente ai client limplementazione di unastrazione –La rappresentazione di una classe è visibile nellinterfaccia della classe stessa 5.Esiste una serie di generalizzazioni annidate 6.Condividere una stessa implementazione fra più oggetti nascondendo la condivisione ai client

53 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software53 Bridge: struttura client Abstraction Operation() RefinedAbstraction Implementor OperationImp() ConcreteImplementorA OperationImp() ConcreteImplementorA OperationImp() imp->OperationImp(); imp

54 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software54 Bridge: partecipanti Abstraction –Definisce linterfaccia dellastrazione –Mantiene un riferimento a un oggetto di tipo Implementor RefinedAbstraction –Estende linterfaccia definita da Abstraction Implementor –Definisce linterfaccia per le classi che implementano lastrazione –Non deve corrispondere esattamente allinterfaccia 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 sulluso di quelle di base ConcreteImplementor –Fornisce linterfaccia Implementor e definisce la sua realizzazione concreta

55 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software55 Bridge: esempio Implementazione dellastrazione Window in un toolkit per interfacce utente: dovrebbe consentire di scrivere applicazioni eseguite indifferentemente su piattaforme x e IBM Presentation Manager: –usando lereditarietà 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 dellinterfaccia WindowImp: Lapproccio consente di disaccoppaire lastrazione fornita dalle implementazioni specifiche: realizza un collegamento fra lastrazione e la sua implementazione

56 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software56 Decorator: scopo Aggiungere dinamicamente responsabilità a un oggetto Fornisce unalternativa flessibile alla definizione di sottoclassi come strumento per lestensione delle funzionalità

57 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software57 Decorator: motivazione Aggiungere responsabilità a singoli oggetti e non a unintera classe –Si può aggiungere responsabilità mediante ereditarietà –Svantaggio: approccio poco flessibile perché si procede staticamente Usare un oggetto contenitore: decorator Il decorator: –ha uninterfaccia conforme a quella dellelemento 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 laggiunta di un numero illimitato di responsabilità agli oggetti decorati

58 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software58 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 –Lestensione attraverso la definizione di sottoclassi non è praticabile: A volte è possibile definire un gran numero di estensioni indipendenti, fatto che porterebbe a unesplosione 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

59 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software59 Decorator: struttura Component Operation() ConcreteComponent Operation() Decorator Operation() ConcreteDecoratorA Operation() ConcreteDecoratorB Operation() AddedBehavior() addedState Component->Operation() Decorator::Operation() AddedBehavior(); component

60 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software60 Decorator: partecipanti Component –Definisce linterfaccia 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 uninterfaccia conforme allinterfaccia di Component ConcreteDecorator –Aggiunge responsabilità al componente

61 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software61 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 dellinterfaccia utente: Il pattern decorator consente di racchiudere il componente da decorare in un altro responsabile dellaggiunta del bordo. Il decorator ha uninterfaccia conforme a quelle dellelemento decorato e trasferisce le richieste al componente decorato

62 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software62 Decorator esempio VisualCcmponent Draw() TextView Draw() Decorator Draw() ScrollDecorator Draw() ScrollTo() BorderDecorator Draw() DrawBorder() scrollPosition component->Draw() Decorator::draw() DrawBorder(); component

63 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software63 Proxy: scopo (detto anche Surrogate) Fornire un surrogato o un segnaposto di un altro oggetto per controllare laccesso a tale oggetto

64 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software64 Proxy: motivazione Controllo dellaccesso di un oggetto: rinviare il costo della sua creazione e inizializzazione fino a quando loggetto non è effettivamente necessario

65 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software65 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 oggetticostosi 3.Un proxy di protezione controlla laccesso 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 lesecuzione di attività aggiuntive quando si accede alloggetto referenziato: –Conteggio del numero di riferimenti alloggetto 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 loggetto rappresentato sia riservato (locked) quando si richiede di accedervi in modo che nessun altro oggetto possa modificarlo

66 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software66 Proxy: struttura Client Subject Request() ….. RealSubject Request() ….. Proxy Request() ….. realSubject … realSubject->Request(); ….

67 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software67 Proxy: partecipanti Proxy –Mantiene un riferimento che consente al Proxy di accedere alloggetto rappresentato RealSubject. –Un Proxy può accedere a un Subject se le interfacce Subject e RealSubject sono identiche –Fornisce uninterfaccia identica a quella definita da subject, consentendo quindi al proxy di agire come un sostituto delloggetto destinazione –Controlla laccesso alloggetto 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é dellinvio della richiesta codificata alloggetto rappresentato, posto in un diverso spazio di indirizzamento proxy virtuali: possono memorizzare informazion addizionali sulloggetto rappresentato allo scopo di posticipare laccesso a tale oggetto proxy di protezione: verificano che il chiamante abbia i permessi di accesso necessari per poter effettuare una richiesta alloggetto rappresentato Subject –Definisce linterfaccia comune per le classi RealSubject e Proxy, rendendo possibile lutilizzo del Proxy in tutte le situazioni in cui è previsto lutilizzo di RealSubject RealSubject –Caratterizza loggetto reale rappresentato dal proxy

68 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software68 Proxy: esempio un editor di documenti che consenta di inserire oggetti grafici allinterno 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 dellimmagine ( un segnaposto per limmagine) –ha lo stesso comportamento dellimmagine vera e propria –si preoccupa di istanziarla quando richiesto il proxy crea limmagine soltanto quando leditor di documenti chiede al proxy di disegnarla sullo schermo invocando loperazione Draw tutte le richieste successive vengono trasferite dal proxy direttamente allimmagine Il proxy deve mantenere un riferimento allimmagine dopo la sua creazione

69 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software69 Proxy: esempio DocumentEditor Graphic Draw() GetExtent() Store Load() ….. Image ImageProxy image if (image==0){ image= LoadImage(fileName)} Image>Draw() Draw() GetExtent() Store Load() ….. Draw() GetExtent() Store Load() ….. imageImp extent filename extent if (image==0){ return extent; } else{ return image>GetExtent(); }

70 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software70 Facade: scopo Fornire uninterfaccia unificata per un insieme di interfacce presenti in un sottosistema Definisce uninterfaccia di livello più alto che rende il sottosistema più semplice da utilizzare

71 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software71 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

72 Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 72 Pattern comportamentali Observer Strategy

73 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software73 Caratteristiche Si occupano di algoritmi e dellassegnamento 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 lesecuzione Spostano lattenzione dal flusso di controllo e si focalizzano sul modo in cui gli oggetti sono interconnessi tra loro.

74 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software74 Caratteristiche Basati su classi: –Utilizzano lereditarietà per distribuire responsabilità e comportamento fra oggetti diversi Basati su oggetti: –Usano la composizione degli oggetti al posto dellereditarietà –Descrivono (alcuni) come un gruppo di oggetti cooperanti possa realizzare funzionalità impossibili per un oggetto singolo –Descrivono come i singoli oggetti si riferiscono luno allaltro: mantenere riferimenti espliciti agli altri oggetti aumenterebbe notevolmente laccoppiamento

75 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software75 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

76 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software76 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 dellaccoppiamento che deve rimanere basso

77 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software77 Observer: applicabilità Il pattern Observer può essere usato nei seguenti casi: –Unastrazione presenta due aspetti, di cui uno dipendente dallaltro. 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 lidentità precisa: si vuole mantenere un alto livello di disaccoppiamento

78 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software78 Observer: 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

79 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software79 Observer: partecipanti Subject –Conosce i propri Observer. Un numero qualsiasi di oggetti Observer può osservare un soggetto –Fornisce uninterfaccia per associare e dissociare oggetti Observer Observer –Fornisce uninterfaccia 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 linterfaccia di notifica di Observer per mantenere il proprio stato consistente con quello del subject

80 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software80 Observer: pattern correlati Mediator: incapsulando una semantica daggiornamento complessa, ChangeManager svolge il ruolo di Mediato fra soggetto e osservatori Singleton: ChangeManager può usare il pattern Singleton per rendersi unico e globalmente accessibile

81 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software81 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

82 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software82 Strategy: motivazione Codificare dinamicamente in classi algoritmi che realizzano le stesse funzionalità È possibile definire delle classi che incapsulano svariati algoritmi mediante il pattern strategy: lalgoritmo incapsulato è chiamato strategy

83 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software83 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 dellalgoritmo –Una classe definisce molti comportamenti che compaiono allinterno di scelte condizionali multiple. Al posto di molte scelte condizionali, si suggerisce di spostare i blocchi di codice correlati in una classe strategy dedicata

84 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software84 Strategy: struttura Context ContextInterface() Strategy ContextInterface() ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() ConcreteStrategyC AlgorithmInterface()

85 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software85 Strategy: partecipanti Strategy (compositor) –Dichiara uninterfaccia comune a tutti gli algoritmi supportati. Context usa questinterfaccia per invocare lalgoritmo definito da un ConcreteStrategy ConcreteStartegy (Simplecompositor, TextCompositor, Arraycompositor) –Implementa lalgoritmo usando linterfaccia Strategy Context (Composition) –È configurato con un oggetto ConcreteStrategy –Contiene un riferimento a un oggetto Strategy –Può definire uninterfaccia che permetta a Strategy di accedere alla sua struttura dati

86 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software86 Strategy: collaborazioni Strategy e Context collaborano per implementare lalgoritmo voluto: Context può passare tutti i dati necessari dallalgoritmo a Strategy quando viene invocato lalgoritmo. 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 loggetto ConcreteStrategy da una famiglia di sottoclassi concrete di Strategy

87 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software87 Strategy: conseguenze Famiglie di algoritmi correlati Unalternativa allereditarietà Le strategie eliminano i blocchi condizionali Scelta dellimplementazione I client devono conoscere le diverse Strategy disponibili Collaborazioni fra Strategy e Context dispendiosa Aumento del numero di oggetti

88 Corso di Laurea Triennale in Ingegneria Informatica Corso di Sistemi Informativi A. A. 2004 - 2005 Marina Mongiello Ingegneria del software 88 Pattern creazionali

89 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software89 Caratteristiche Forniscono unastrazione del processo di istanziazione degli oggetti Aiutano a rendere un sistema indipendente dalla modalità di creazione, composizione e rappresentazione degli oggetti utilizzati

90 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software90 Caratteristiche Basati su classi: utilizza lereditarietà per scegliere le particolari classe da istanziare Basati su oggetti: delega listanziazione a un altro oggetto

91 Sistemi Informativi DEE - Politecnico di Bari Marina Mongiello Ingegneria del software91 Caratteristiche Capacità di incapsulare la conoscenza delle classi concrete utilizzate nel sistema Capacità di nascondere le modalità di creazione e composizione di tali classi