Laboratorio di Ingegneria del Software Andrea Bei
Altri pattern GRASP Altri pattern GRASP Polymorphism Pure Fabrication, Indirection Protected Variations 2
Polymorphism Problema: Come gestire alternative basate sul tipo? Se a seconda del tipo di una classe si devono eseguire operazioni diverse come si possono evitare espressioni ifthen-else che rendono poco estendibile il codice all introduzione di nuovi tipi? Come creare componenti software inseribili? Se A dipende da B come si può sostituire l implementazione di B senza ripercussioni su A? Soluzione: Se alternative o comportamenti variano con il tipo assegnare la responsabilità del comportamento a tipi con operazioni polimorfe ( dare lo stesso nome a servizi diversi ) 3
Polymorphism: esempio 1 Studio di Caso POS «interface» ITaxCalculatorAdapter gettaxes( Sale ) : List<TaxLineItems> TaxMasterAdapter gettaxes( Sale ) : List<TaxLineItems> GoodAsGoldTaxPro Adapter gettaxes( Sale ) : List<TaxLineItems>...... <???>Adapter Per il polimorfismo più calcolatori delle tasse hanno By Polymorphism, un comportamento multiple tax calculator simile adapters ma variabile have per their adattarsi own similar, ai but diversi varying calcolatori behavior for adapting delle tasse to esterni different external tax calculators. 4
Polymorphism: esempio 1 Studio di Caso POS : Sale :TaxMasterAdapter t = gettotal... taxes = gettaxes( s ) TCP socket communication xxx... «actor» :TaxMasterSystem Gli the adapter agiscono acts as a level da of livello di indirezione indirection to external per i sistemi systems esterni fornendo all interno una interfaccia stabile 5
Polymorphism: esempio 2 Studio di Caso Monopoly Ogni Square ha il metodo landedon ( posato su ) che rappresenta l atto di finire su ( landed On ) una Square da parte di un giocatore. Il metodo landedon ha un comportamento diverso a seconda del tipo di Square (alternative basate sul tipo).ad es. se il giocatore finisce sulla GoSquare riceve 200 $ mentre se finisce su una RegularSquare non succede nulla 6
Polymorphism: esempio 2 Studio di Caso Monopoly landedon è un metodo astratto: Questo diagramma non dettaglia ulteriormente con i metodi che vengono chiamati da landedon Si creano tanti diagrammi quante sono le alternative basate sul tipo 7
Polymorphism: esempio 2 Studio di Caso Monopoly Si inseriscono tanti diagrammi di interazione quanti sono i comportamenti possibili del metodo polimorfo. Ovvero quanti sono i tipi alternativi possibili 1 2 3 8
Polymorphism: classi astratte e interfacce Come usare il polimorfismo? Con classi astratte e interfacce per introdurre punti di evoluzione e variazione flessibili Per ogni gerarchia di classi con una classe astratta C1 come radice si crei una interfaccia I1 che contenga le firme dei metodi pubblici di C1 e poi si dichiari l implementazione di I1 da parte di C1 9
Pure Fabrication ( pura invenzione ) Problema: A quale oggetto si deve assegnare la responsabilità quando la soluzione suggerita da Expert non è appropriata perchè in conflitto con High Cohesion e Low Copuling? Soluzione: Assegnare un insieme altamente coeso di responsabilità ad una classe artificiale che non rappresenta una classe concettuale del dominio è creata per sostenere High Cohesion, Low Copuling e riuso 10
Pure Fabrication: esempio 1 Studio di Caso POS time Sale Problema: Chi deve avere la responsabilità di salvare i dati di una vendita? 1 Soluzione (Poor Design) Per Expert è Sale. Ma questo aumenta l accoppiamento di Sale (conflitto con Low Coupling) e diminuisce la coesione di Sale (conflitto con High Cohesion) 1 Sales LineItem quantity Contains 1..* * Described-by 1 Product Description description price itemid 2 Soluzione Si applica PureFabrication creando una classe artificiale altamente coesa e altamente riusabile (gestisce Object e non solo Sale) chiamata PersistentStorage. 11
Pure Fabrication: esempio 2 Studio di Caso Monopoly Problema: Chi deve avere la responsabilità di gestire i dadi? 1 Soluzione (Poor Design) Per Expert potrebbe essere Player. Ma questo accoppia la classe Die al Player del Monopoly senza la possibilità di riusare facilmente la classe Die (ad esempio per un altro gioco con i dadi) 2 Soluzione Si applica PureFabrication creando una classe Cup che inoltre ha anche la possibilità di mantenere il risultato dell ultima giocata dei dadi 12
Pure Fabrication e decomposizione La progettazione può dar luogo a oggetti appartenenti a due gruppi: Scelti per decomposizione rappresentazionale Quelli scelti per LRG dal modello concettuale (o di dominio) Scelti per decomposizione comportamentale Quelli artificiali prodotti con Pure Fabrication La decomposizione comportamentale è utilizzata principalmente nella progettazione di architetture e pattern La decomposizione rappresentazionale è utilizzata principalmente nella realizzazione dei casi d uso (logica di business) 13
Pure Fabrication: vantaggi e controindicazioni Vantaggi High Coesion Per costruzione Pure Fabrication da luogo a classi con un insieme altamente coeso di responsabilità Alta riusabilità Essendo le Pure Fabrication classi meno legate al dominio è possibile riusarle in più domini distinti Controindicazioni Pure Fabrication se usato in modo eccessivo può portare ad avere molte classi con responsabilità non associate alle informazioni necessarie per assolverle causando un alto accoppiamento con classi Expert. 14
Indirection Problema: Come assegnare una responsabilità per evitare l accoppiamento diretto tra due elementi? Come disaccoppiare gli oggetti per sostenere Low Copuling e alto riuso? Soluzione: Assegnare la responsabilità ad un oggetto intermediario tra i due elementi in modo che non ci sia un accoppiamento diretto tra essi 15
Indirection: esempio Studio di Caso POS Come disaccoppiare Sale dallo specifico TaxMasterSystem (calcolatore delle tasse)? Per Indirection si introduce un oggetto TaxMasterAdapter che fa da intermediario e aggiunge un livello di indirezione Con un livello di indirezione e il polimorfismo gli Adapter proteggono Sale da variazioni delle interfacce esterne : Sale :TaxMasterAdapter t = gettotal... taxes = gettaxes( s ) TCP socket communication xxx... «actor» :TaxMasterSystem L Adpater the adapter acts agisce as a come level of livello indirection indirezione to external systems verso i sistemi esterni 16
Protected Variations Problema:come progettare oggetti, sottosistemi e sistemi in modo che le variazioni o l instabilità in questi elementi non abbiano un impatto indesiderato su altri elementi? Soluzione: Identificare i punti in cui sono previste variazioni o instabilità Punti di variazione (variazione nei requisiti correnti) Punti di evoluzione (potenziale variazione futura) Assegnare responsabilità per creare attorno ad essi un interfaccia stabile E uno principio importante della progettazione del software. Esempi di PV sono: polimorfismo, interfacce,macchine virtuali, sistemi operativi 17
Protected Variations: meccanismi Meccanismi principali Incapsulamento, interfacce, polimorfismo, indirezioni Progettazione guidata dai dati (design data-driven) Lettura di dati ( path di file, nomi di classi,...) da una sorgente esterna per cambiare il comportamento del sistema o parametrizzarlo durante l esecuzione Lookup di servizi Utilizzo di servizi di naming (es: JNDI in Java) per ottenere un servizio. I Client sono protetti da variazioni nella posizione dei servizi grazie all interfaccia stabile del servizio di lookup Progettazione guidata da interprete (design interpreter-driven) Utilizzo di interpreti per regole che eseguono regole lette da sorgenti esterne (interpreti di script, macchine virtuali, motori neurali, motori di logiche) 18
Protected Variations: meccanismi Progettazione riflessiva o di meta-livello Costrutti e meccanismi di introspezione per modificare a tempo di esecuzione attributi e metodi di classi. Accesso Uniforme Alcuni linguaggi (Ada, Eiffel e C#) offrono un metodo di accesso uniforme a attributi e metodi (es: acircle.radius a seconda delle situazioni può accedere all attributo radius o invocare il metodo radius()) Linguaggi standard L utilizzo di linguaggi standard (SQL) garantisce la protezione dalla variazione delle tecnologie che utilizzano tali linguaggi (es: diversi database) 19
Protected Variations: meccanismi Legge di Demeter o Don t Talk to Strangers Evitare di creare progetti in cui gli oggetti inviano messaggi (parlano) a oggetti lontani e indiretti (stranieri) Violare la legge di Demeter significa rendere i progetti fragili rispetto alle variazioni della struttura degli oggetti (variazioni comuni soprattutto nelle prime iterazioni) Per la legge di Demeter all interno di un metodo i messaggi possono essere inviati solo a: L oggetto this Un parametro del metodo Un attributo this Un elemento di una collezione che è un attributo di this Un oggetto creato all interno del metodo 20
Protected Variations: meccanismi Un esempio che viola leggermente la legge di Demeter. Distanza 1 Un esempio che viola maggiormente la legge di Demeter. Distanza 2 21