Data - Informatica
Transcript
Data - Informatica
Design Pattern GRASP Ingegneria del Software - parte II Andrea Bei Altri pattern GRASP Altri pattern GRASP Polymorphism Pure Fabrication, Indirection Protected Variations RDD 2 2 Polymorphism Problema: Come gestire alternative basate sul tipo ? Come creare componenti software inseribili ? RDD 2 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 ? 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 GoodAsGoldTaxPro Adapter <???>Adapter ... ... getTaxes( Sale ) : List<TaxLineItems> getTaxes( Sale ) : List<TaxLineItems> Per il polimorfismo più calcolatori delle tasse hanno un comportamento simileadapters ma variabile By Polymorphism, multiple tax calculator have their own similar, but varying behavior for adapting to per adattarsi ai diversi calcolatori delle tasse different external tax calculators. esterni RDD 2 4 Polymorphism: esempio 1 Studio di Caso POS : Sale :TaxMasterAdapter t = getTotal TCP socket communication taxes = getTaxes( s ) xxx ... ... «actor» :TaxMasterSystem Gli the adapter da oflivello adapteragiscono acts as a level di indirezione per i sistemi indirection to external systems esterni fornendo all’interno una interfaccia stabile RDD 2 5 Polymorphism: esempio 2 Studio di Caso Monopoly RDD 2 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 RDD 2 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 RDD 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 RDD 2 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 RDD 2 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 Sale time 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 Contains 1..* Sales LineItem quantity * 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. RDD 2 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 RDD 2 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) RDD 2 13 Pure Fabrication: vantaggi e controindicazioni Vantaggi High Per costruzione Pure Fabrication da luogo a classi con un insieme altamente coeso di responsabilità Alta Coesion 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. RDD 2 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 ? RDD 2 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 TCP socket communication taxes = getTaxes( s ) xxx ... ... «actor» :TaxMasterSystem L’Adpater agisce the adapter acts as acome level of livello di indirezione verso indirection to external systems i sistemi esterni RDD 2 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à RDD 2 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 Progettazione guidata dai dati (design data-driven) 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) RDD 2 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 Incapsulamento, interfacce, polimorfismo, indirezioni 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 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 RDD 2 Costrutti e meccanismi di “introspezione” per modificare a tempo di esecuzione attributi e metodi di classi. 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 Per la legge di Demeter all’interno di un metodo i messaggi possono essere inviati solo a: RDD 2 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) 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 RDD 2 21