Appunti di Progettazione del Software, tutte le lezioni

DESIGN PATTERN

Abbiamo già parlato di pattern sw e sappiamo che sono soluzioni trovate a particolari

problemi di progettazione e al quale viene dato un nome standard che facilita anche la

comunicazione tra proggettisti.

Un pattern software è una soluzione provata e ampiamente applicabile a un particolare

problema di progettazione, scritta in una forma standard

Tipi di pattern software

pattern GRASP (principi per assegnazione responsabilità e generali)

• design pattern (certo numero di oggetti e classi che interagiscono tra loro. Grana

• piccola) 106

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

pattern architetturali (elemnti a grana grossa come strato che racchiude decine o

• centinaia di classi)

idiomi di programmazione (grana piccola soluzione a manciata di istruzioni)

•

si diversificano per livello di granularità.

Definizione di design pattern:

Un design pattern è la descrizione di classi e oggetti che comunicano, personalizzati per

risolvere un problema generale di progettazione in un contesto particolare

Un design pattern è pattern sw e la sua granuralità è piccola. La descrizione di soluzione è

definiti in termini di classi(aspetti statici della struttura della soluzione) e oggetti che

comunicano (soluzione parla di interazioni motivate dal pattern). La soluzione di questo

pattern è fatta da parte statica e dinamica.

Problemi ricorrenti ma più specifici rispetto ai pattern grasp.

Esistono numerosi design pattern ma i più diffusi sono 23.

Banda di 4 (gof – gang of four) = 4 autori del primo libro sul tema

Tipi di design pattern

strutturali (servono a risolvere problemi per gestire info a struttura complessa e

• quindi problema e soluzione riguarda struttura info)

creazionali (problemi complessi creazione di oggetti)

• comportamentali (implementazione di comportamento complessa)

•

PROGETTARE CON I DESIGN PATTERN

Vediamo una serie di problemi risolti con alcuni design pattern gof.

Problema di progettazione

inviare dati sulla vendita completata al sistema esterno di Contabilità

• più in generale, interagire con sistemi/servizi esterni

•

il problema è che in istallazioni diverse del ns sw possono esserci diversi sistemi esterni che

offrono operazioni simili ma in istallazioni diverse possono esserci diversi sistemi con cui

interagire in modo diverso…

Design Pattern Adapter

problema: come gestire interfacce incompatibili, o fornire un’interfaccia stabile a

• componenti simili ma con interfacce diverse? (considerando coppie di oggetti client-

server in cui server offre servizi e client che vuole fruire di servizi è il caso che il server

offre servizi con certa modalità ma client vuole usare servizi con operazioni diverse…

in questo caso parliamo di interfacce incompatibili tra client e server. Ese: client

oggetto del dominio in cui richiesta è paramento vendita di POS ma server è oggetto si

107

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

sistema esterno che ha dati vednita in formato diverso –xml, reste cc… incompatibilità

delle richieste tra client e server.)

soluzione: converti l’interfaccia originale di un componente in un’altra interfaccia,

• attraverso un oggetto adattatore intermedio (introducendo un intermediario che fa

conversione interfaccia. Converte richieste client in formato accettabile per server e

viceversa. Adattatore che converte le richieste e e risposte)

figura sotto possibile soluzione strutturale per questo problema con adattatore che fornisce

soluzione per invio dati su vendita completata a sistema erp. Con polimorfismo per ogni

sistema estenro di contabilità c’è un diverso adattatore che realizza adattamento in modo

diverso.

a secondo tipo adattatore, questo converte dati in formato comprensibile da sistema esterno.

108

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

descrizione generale della soluzione in figura sotto:

2 elementi: interfaccia gradita al client e una o più implementaizoni per adattatore e ogni

interfacci fa adattamento richista tra client e server.

ulteriore problema di progettazione

chi crea gli adattatori? come determinare il tipo specifico di adattatore da utilizzare?

•

Non possiamo usare creator ma dobbiamo identificare pure fabrication per questa

responsabilità. Dobbiamo quindi usare il pattern factory

Design Pattern Factory

problema: chi deve essere responsabile della creazione di oggetti quando ci sono

• considerazioni speciali? ( considerazioni speciali: oggetto da creare non è ispirato a

dominio quindi pure fab. E quindi non si applica creator. In sistallazioni diverse mi

servono adattatori diversi. Devo leggere nome adattatore in file di conf. E questa

responsabilità non si può dare ad oggetto del dominio.)

soluzione: fornisci un’interfaccia per la creazione di un oggetto senza bisogno di

• specificare quale sia la sua classe concreta

nel ns problema possiamo usare services factory che fornisce operazione

getaccountingadapter per avere riferimento adattatore per sistema ext di erp. 109

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

possibile implementazione metodo getacc.ada.

se null: adattatore da creare e restituito.

Per crearlo si usa in java soluzione su riflessione e su progetto guidato dai dati per cui si usa

variabile per nome tipo di adattatore leggendo nome da proprietà di sistema o da fole conf. E

poi usando classi riflessione java per creare nuova istanza del tipo che corrisponde a questo

nome class.forname… seguito da cast dell’interfaccia dell’adattatore.

Così ogni istallazione si può cambiare scelta adattatore senza cambiare codice ma cambiano

solo info in file di configurazione.

ancora esiste questo pProblema di progettazione

chi crea la factory, e come si accede ad essa? (avere visibilità globale vs la factory così

• che ogni oggetto possa accedere ad adattatori

Design Pattern Singleton (singoletto)

problema: è richiesta una sola istanza di una classe – singleton - , e gli altri oggetti

• hanno bisogno di un punto di accesso globale a questo oggetto (oggetto che vogliamo

vedere globalmente può essere la service factory.)

soluzione: definisci un metodo statico della classe che restituisce il singleton (soluzone

• tecnica… dipende anche da linghuaggio programmazione usato..)

in java possiamo dire che classe services è singleton. Questo si fa scrivendo 1 in alto a dx della

classe. 110

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Il design pattern usa variabile istanza statica – di classe – e metodo di classe – statico- che si

chiamano: istance e getistance.

metodo getistance è pubblico e restituisce oggetto servicesfactory.

Se istanza non creata – null – crea istanza di questo oggetto…

Diverse esecuzioni di questo metodo portano creazione dello stesso ogetto.

Costruttore classe servicefactory privato non può essere creato da esterno a questa classe.

interazione con sistema esterno avviene mediante adapter. Questi creati con factory e facroty

acceduta mediante singleton. Usando conoscenza pattern si può discutere progetto complesso

in forma sintetica. I gof sono molto conosciuti quindi è comune parlare in termini di pattern.

111

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

Problema di progettazione

come progettare il collegamento tra lo strato del dominio e il servizio di persistenza

• degli oggetti?

Vogliamo che accoppiamento tra dominio e sottosistema di persistenza sia basso.

Design Pattern Facade (facciata)

problema: è richiesta un’interfaccia comune e unificata per un insieme disparato di

• classi e interfacce, come per definire un sottosistema (caso della gestione persistenza.

Vogliamo definire sottosistema come implementazione di classi e interfacce ma non

vogliamo accoppiamento con queste classi ma accoppiamento rispetto con interfaccia

comune e semplificata con sottosistema)

soluzione: definisci un punto di contatto singolo con il sottosistema: un oggetto facade

• che copre il sottosistema (facciata che riduce accoppiamento come facciata di palazzo,

copre nasconde implementazione sottosistema così che facciata è pubblica e

implementazione è privata.)

in rettangolo grande racchiusa implementazione. Dall esterno si accede solo alla facade. Come

facade persistencestorage facade. Questo è intermediario che riduce accoppiamento vs

sottosistema.

Pattern grasp controller può essere come facade controller che nasconde a presentazione

oggetti del dominio ed è punto accesso al dominio.

Problema di progettazione

aggiornare il totale della vendita quando viene inserito un nuovo articolo

• più in generale, come gestire il collegamento tra strato del dominio e UI?

•

Si parla di Visualizzazione info e risultato interrogazione

Possibili soluzioni 112

A Cura di Stefano Silvani. UTIU – Il presente materiale è stato realizzato a fini didattici. Ne è vietata qualsiasi riproduzione,

manipolazione e vendita non autorizzata.

pull (presentazione fa richieste vs strato dominio quando sa che ci sono cambiamento.

• Ese: presentazione chiede tot vendita aggiornata quando sa che tot cambia. Quando

presentazione non conosce che c’è cambiamento bisogna trovare soluzione)

polling (interfaccia utente chiede strato dominio se è cambiata vendita. Se

• presentazione deve visualizzare tante info allora deve chiedere continuamente allo

strato del dominio info aggiornate)

push (oggetti del dominio che quando verificano cambiamenti li notificano cosi che la

• presentazione visualizza i nuovi valori in automatico. questa soluzione è problematica

perché in architettura a strati le dipendenze sono dall’alto vs il basso. Si vuole evitare

che il dominio vada vs presentazione. Evitare accoppiamento diretto e usare

accoppiamento