31
Progettazione di software

Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Embed Size (px)

Citation preview

Page 1: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Progettazione di software

Page 2: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Pericoli dell’ereditarietà

• Spesso si usa l’ereditarietà dove non si dovrebbe

Page 3: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Aggregati errati

• Usare l’ereditarietà dove serve aggregazione– Aereo usa le operazioni di ala, coda, motore…– Aereo è composto da…

Page 4: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Gerarchie invertite

• Dipendente eredita da Dirigente che eredita da MembroConsiglioAmministrazione

• È il contrario!!!!!!!!!!

Page 5: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Confusione tra classe e istanza

• Panda eredita da Orso e da SpecieProtetta• Errato:

– un’istanza di Orso è Yoghi– Un’istanza di Panda è Ling-Ling– Un’istanza di SpecieProtetta è Panda

• Soluzione corretta: un animale ha un attributo specie che nel caso della classe Panda è istanza di SpecieProtetta

Page 6: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Applicazione errata di è-un (is-a)

• Stanza eredita da Parallelepipedo• E se ho una stanza cilindrica?• Errato: Stanza ha una Forma uguale a

Parallelepipedo

Page 7: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza

• Letteralmente: “essere nati insieme” o “avere destini intrecciati nella propria vita”

• Due elementi software conascenti derivano da esigenze software correlate

• A e B sono conascenti se è possibile postulare dei cambiamenti di A che richiederebbero cambiamenti di B (o viceversa)

Page 8: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza – esempio banale

int i;

i=7;

Le due linee sono conascenti

Page 9: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza di nome

• Due variabili devono avere lo stesso nome per fare riferimento alla stessa cosa

• Nell’esempio entrambe le righe usano i• Se una sottoclasse usa un attributo di una

sovraclasse deve identificarlo col nome dato nella sovraclasse

Page 10: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza di convenzione

• Più parti sono costruite in base a una convenzione fissata– Esempio: i conti delle persone hanno un id

positivo, quelli delle società negativo

• Nascono ad esempio da costanti nel codice– 0:nord 1:sud…

Page 11: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza di algoritmo

• Una classe usa un certo algoritmo per eseguire una certa operazione basato su certe ipotesi sui dati (input o output)

Page 12: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza temporale

• Esiste nei sistemi real-time• Esempio: il cancello va chiuso 20 secondi

dopo essere stato aperto

Page 13: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza di valore

• Vincoli aritmetici sui valori– Gli angoli di un quadrilatero hanno somma 360

• Nasce dalla ridondanza

Page 14: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Contronascenza

• Due cose devono essere diverse

int i;

int j;

• È una conascenza dove invece dell’uguale c’è il diverso

Page 15: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conascenza e incapsulamento

• L’incapsulamento riduce la conascenza• Meno conascenza c’è meglio è• Quella residua deve essere documentata

Page 16: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Manutenibilità

• Il software può essere mantenuto se:– Si riduce al minimo la conascenza– Tutta la conascenza residua è confinata

nell’incapsulamento

Page 17: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Domini delle classi di oggetti

• Le classi non sono tutte uguali• 4 domini

– Dominio applicativo– Dominio aziendale– Dominio architetturale– Dominio fondazionale

Page 18: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Dominio applicativo

• Classi per riconoscere eventi– BottoneCliccato– TemperaturaTroppoAlta

• Classi per gestire eventi– RiscaldamentoPazienteIpotermico

Page 19: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Dominio aziendale

• Classi di attributo: catturano le proprietà tipiche di un certo dominio aziendale– Saldo, TemperaturaCorporea

• Classi di ruolo: derivano dai diversi ruoli che un’entità può avere– Paziente, Cliente

• Classi di relazione: derivano da associazioni tipiche dei diversi contesti– IntestazioneConto, SupervisionePaziente

Page 20: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Dominio architetturale

• Classi per l’interfaccia utente• Classi per la gestione delle basi di dati• Classi per la comunicazione di rete

Page 21: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Dominio fondazionale

• Classi fondamentali– Boolean, Char, …

• Classi strutturali– Vector, Stack, …

• Classi semantiche– Angolo, Ora, Massa, Linea, Cerchio, …

Page 22: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

In ordine di riutilizzabilità

• Nessuno scrive più le ultime, tutti devono farsi le prime

• In mezzo dipende…

Page 23: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Ingombro

• Misura l’equipaggiamento ausiliario di una classe

• Conta le classi a cui una classe si deve affidare per funzionare (contando anche quelle a cui fanno riferimento quelle a cui fa riferimento, e così via)

Page 24: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Ingombro

• C eredita da D• C contiene un attributo di tipo D• C ha un’operazione con un parametro di

tipo D• C ha una variabile di tipo D• C ha un metodo con tipo restituito di tipo D• …

Page 25: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Ingombro

• L’ingombro è più basso nelle classi fondamentali e cresce nelle altre

• Da ridurre il più possibile…

Page 26: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Coesione di classe

• È la misura della corrispondenza reciproca fra le caratteristiche (attributi e metodi) situati nell’interfaccia esterna di una classe

• Bassa coesione: insieme di caratteristiche slegate

• Alta coesione: insieme di caratteristiche che insieme contribuiscono a costruire l’astrazione rappresentata dalla classe

Page 27: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Violazioni della coesione

• Coesione a istanza mista• Coesione a dominio misto• Coesione a ruolo misto

– In ordine decrescente di gravità

Page 28: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Coesione a istanza mista

• Ha caratteristiche indefinite per alcuni oggeti della classe– Dipendenti: solo alcuni possono prendere

provvigioni– Il metodo emettiPagamentoProvvigioni– Potrebbe emettere un pagamento pari a 0

• Orrendo!!!!!!

Page 29: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Coesione a dominio misto

• Contiene un elemento che la ingombra direttamente con una classe estrinseca appartenente a un dominio diverso– Mettere nella classe Real il metodo

equivalenteInGradiCelsius

Page 30: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Coesione a ruolo misto

• Contiene un elemento che ingombra la classe con una classe estrinseca appartenente allo stesso dominio– Mettere in persona l’attributo

numeroDiCaniPosseduti

Page 31: Progettazione di software. Pericoli dell’ereditarietà Spesso si usa l’ereditarietà dove non si dovrebbe

Conformità di tipo

• Se S è un sottotipo di T, allora S può essere fornito dovunque ci si aspetti T e la correttezza viene mantenuta– Cerchio sottotipo di Ellisse