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