Il fenomeno del riuso, ovvero di fare nuovamente uso di qualcosa di gi`a adoperato, per lo stesso scopo o per uno diverso, `e antico quanto l’uomo e riguarda tutti i campi dell’umano agire: dalla cucina all’architettura fino alla tecnologia dell’informazione.
In particolare in informatica, il riuso del codice consiste nella prassi di uti- lizzare parti di codice precedentemente gi`a scritte ogniqualvolta ci`o risulti necessario, evitando il costo dovuto alla riscrittura dello stesso. Nel caso in cui si consideri un particolare programma, tale azione pu`o essere por- tata a buon termine attraverso la scrittura di funzioni che possono essere invocate all’interno dello stesso programma; nel caso in cui si considerino programmi diversi, questo pu`o avvenire attraverso la creazione di opportune
Musei -museo[1..*] +getMuseo() +addMuseo() Museo -coordinate: Coordinate -descrizione: Descrizione -id: Id +getCoordinate() +getDescrizione() +getId() +setCoordinate() +setDescrizione() +setId() Coordinate -data +getData() +setData() Id -data +getData() +setData() Descrizione -indirizzo -nome -sitoWeb -telefono +getIndirizzo() +getNome() +getSitoWeb() +getTelefono() +setIndirizzo() +setNome() +setSitoWeb() +setTelefono() Nome -data +getData() +setData() Indirizzo -data +getData() +setData() SitoWeb -data +getData() +setData() Telefono -data +getData() +setData()
Figura 6.1: Diagramma delle classi relativo agli Open Data del Comune di Firenze.
librerie che possono essere invocate all’interno dei programmi oppure delle cosiddette API (Application Programming Interface).
Nel seguito del presente paragrafo, sar`a presentato un caso di esempio che servir`a a rendere pi`u chiara la modalit`a attraverso la quale l’IDN Template abilita il riuso dei dati.
Si consideri adesso il caso di un programmatore che sia intenzionato a creare un’applicazione all’interno della quale sia riutilizzato il codice derivato al diagramma UML illustrato in figura 6.1; questo `e lo stesso diagramma che era stato ottenuto nell’esempio descritto nel paragrafo 5.3.
Si supponga, ad esempio, che egli non abbia a disposizione il sorgente di tale codice, ma che sia riuscito ad ottenerne in qualche modo — fornitogli di- rettamente dal programmatore originale, scaricato dal sito web dello stesso, ecc. . . – una versione eseguibile, ma non modificabile; ad esempio nel caso in
6.1 Il riuso del codice 119
cui fosse stato utilizzato Java come linguaggio di programmazione, questo potrebbe essere un pacchetto JAR, dal quale `e possibile ottenere la signature dei vari metodi, ma al quale non `e possibile effettuare modifiche. Oppure, si ipotizzi ancora, che sia riuscito ad ottenere, sempre attraverso una delle modalit`a precedentemente descritte, il codice sorgente relativo all’esempio considerato, ma tuttavia non voglia per esigenze pratiche provvedere ad ap- portarvi modifiche (ad esempio perch´e ritiene che questa sia un’operazione eccessivamente onerosa).
Pertanto, egli vuole utilizzare tale codice come una scatola nera1; allo stes- so tempo gradirebbe che esso avesse una struttura lievemente diversa, ad esempio che il museo godesse della caratteristica di possedere un direttore, del quale specificare il nome. Inoltre, poich´e ritiene che l’informazione id non sia significativa per le finalit`a di suo interesse, desidererebbe che essa non fosse presente.
Di fronte a tale esigenza, il programmatore dispone di due possibilit`a: • riscrivere completamente ex novo il programma (ma questo contrasta
con le esigenze del riuso);
• adottare un’opportuna strategia di programmazione che gli consenta di adattare il codice.
Nel seguito sar`a illustrata una modalit`a utile al fine di perseguire quest’ul- tima strada.
6.1.1 Il design pattern Adapter
All’interno della letteratura scientifica `e stata ormai illustrata da anni una soluzione al problema posto poco sopra; in particolare essa consiste nell’u- tilizzo del design pattern Adapter.
Nell’Ingegneria del Software, il termine design pattern indica una soluzione progettuale generale ad un problema ricorrente: non si tratta di una libreria o di un componente software riutilizzabile, ma di un modello da applicare per la soluzione di un problema che pu`o presentarsi in svariate situazioni durante la progettazione e lo sviluppo del software.
Il termine design pattern fu introdotto inizialmente nell’architettura [AIS+77] e fu usato pi`u tardi nell’Ingegneria del Software grazie al lavoro di Gamma et al. [GHJV95], generalmente noti come la “Banda dei quattro” (Gang of four ). In tale libro gli autori identificarono 23 design pattern, tra i quali `e annoverato anche l’Adapter.
Lo scopo di tale design pattern `e quello di convertire l’interfaccia di una classe in un’altra interfaccia richiesta dal client, consentendo a classi diverse
1
Nella Teoria dei Sistemi il termine scatola nera (o blackbox ) indica un sistema del
quale non `e noto a priori ne’ ci`o che contiene, ne’ come si comporta, ma che `e descrivibile
Client Target +Request() Adapter +Request() Adaptee +SpecificRequest() adaptee adaptee->SpecificRequest()
Figura 6.2: Struttura del design pattern Adapter.
di operare insieme quando ci`o non sarebbe altrimenti possibile a causa di interfacce incompatibili.
Capita spesso infatti che una classe di supporto non possa essere riusata all’interno di una applicazione semplicemente perch´e la sua interfaccia non `e compatibile con l’interfaccia specifica richiesta da un’applicazione stessa. Il pattern, la cui struttura `e illustrata nella figura 6.2, si compone dei seguenti quattro partecipanti:
• Target: definisce l’interfaccia specifica del dominio utilizzata dal client; • Client: collabora con oggetti compatibili con l’interfaccia Target ; • Adaptee: individua un’interfaccia esistente che deve essere adattata; • Adapter: adatta l’interfaccia di Adaptee all’interfaccia di Target. L’utilizzo del pattern Adapter richiede di prendere in considerazione il fat- to che la complessit`a degli adattatori varia in base alla quantit`a di lavoro che deve essere svolta per adattare Adaptee all’interfaccia Target. Esiste uno spettro di possibilit`a che va dalla semplice conversione di interfaccia, per esempio il cambio dei nomi delle operazioni, fino a fornire un insieme completamente diverso di operazioni. Pertanto la quantit`a di lavoro svolto da un Adapter `e strettamente legata alle similarit`a esistenti tra l’interfaccia Target e quella di Adaptee.
Ritornando al problema di esempio precedentemente preso in considerazione, il programmatore pu`o decidere di applicare il pattern Adapter e a partire dall’originale diagramma delle classi, presentato in figura 6.1, ottenere il diagramma delle classi riportato in figura 6.3.
6.2 Il riuso dei dati 121