Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 16.Design Patterns – Parte seconda


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.

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.


Composite


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.

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.

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.

Composite

Conseguenze …..

Semplifica il client: il client può trattare strutture composte e singoli oggetti in modo uniforme.

Rende più 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).

Può rendere il progetto troppo generico per la facile aggiunta di nuove componenti.

Esempio in C++


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.

Categoria Behavioral (segue)


Categoria Behavioral (segue)


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.

Si usa:

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

Observer: la struttura


Observer: comportamento dinamico


Esempio


Esempio (segue)

Nell’ambito della realizzazione del software suddetto, si vuole gestire anche un attributo valore nella classe AzioniAcquistate che misuri il valore istantaneo di un insieme di azioni acquistate.

Esso è calcolato come:

AzioniAcquistate.valore = Società.quotazione * AzioniAcquistate.quantità

Allorché il sistema aggiorna il valore della quotazione delle azioni di una società (ovvero l’attributo Società.quotazione), si vuole che gli attributi valore delle istanze delle classi AzioniAcquistate siano automaticamente aggiornati.


Soluzione con observer


Pattern comportamentali: Strategy

Contesto:
Un metodo può essere risolto con diversi algoritmi e si vuole scegliere dinamicamente l’algoritmo da utilizzare.

Problema:
La scelta dell’algorimo deve avvenire a tempo di esecuzione:
Deve essere possibile aggiungere nuovi algoritmi risolutivi;
I codici degli algoritmi sono indipendenti tra loro.

Soluzione:
Creare una classe astratta Strategy che ammetta come sue implementazioni delle classi con un metodo che fornisca una soluzione al problema. Inserire nella classe utilizzatrice un legame ad una implementazione della classe Strategy che possa essere scelta dinamicamente.

Strategy: la struttura

Il costruttore dell’oggetto Context deve settare sicuramente l’attributo strategy, che deve puntare ad un oggetto che istanzia una delle implementazioni concrete della classe astratta Strategy.
La chiamata di execute su un oggetto Context causa l’esecuzione dell’algoritmo della classe concreta strategy scelta.
Il metodo setStrategy di Context permette di modificare dinamicamente la strategia scelta.

Strategy: esempi

Si consideri la classe Albero come Context

  • Le varie visite dell’albero (in ampiezza, in profondità, …) rappresentano soluzioni alternative al problema della visita, che hanno la stessa interfaccia.
  • Possono essere implementate in distinte classi Visita che fanno le veci delle ConcreteStrategy.

Si consideri una classe Lista come Context

  • I possibili algoritmi di ordinamento della lista possono diventare metodi di classi ConcreteOrdinamento che forniscono implementazioni alternative del metodo di ordinamento.

Si noti esplicitamente che l’adozione di una strategia può avvenire in maniera trasparente rispetto ad un utente della classe Context.

  • Questa strategia è anche coerente con un modello a servizi nel quale alle diverse implementazioni di algorithm potrebbero corrispondere, ad esempio, a chiamate a servizi web o comunque remoti.

I materiali di supporto della lezione

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

Marcello Esposito, Elementi per la progettazione di Software Object-Oriented riusabile ed estensibile.

Design Patterns

dofactory

dpatoolkit

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion