1 Le gerarchie di tipi: implementazioni multiple e principio di sostituzione

2 Come si può utilizzare una gerarchia di tipi 4 Il sottotipo estende il comportamento del tipo –fornendo nuovi metodi 4 Implementazioni multiple di un tipo –i sottotipi non aggiungono alcun comportamento nuovo –la classe che implementa il sottotipo implementa esattamente il comportamento definito dal supertipo 4 dal punto di vista semantico, supertipo e sottotipo sono legati dal principio di sostituzione: un oggetto del sottotipo può essere sostituito ad un oggetto del supertipo senza influire sul comportamento dei programmi che utilizzano il tipo

3 Implementazioni multiple 4 il tipo superiore della gerarchia –un’interfaccia (solo specifica) –una classe astratta (implementazione parziale) 4 definisce una famiglia di tipi tale per cui –tutti i membri hanno esattamente gli stessi metodi e la stessa semantica per esempio, ci potrebbero essere implementazioni sparse e dense dei polinomi, realizzate con sottoclassi –che forniscono l’implementazione di tutti i metodi astratti, in accordo con le specifiche del supertipo –in più hanno i costruttori

4 Implementazioni multiple 4 Supponiamo di avere due implementazioni per i polinomi un programma potrebbe voler usare tutte e due le implementazione (scegliendo ogni volta la più adeguata) La scelta viene fatta chiamando uno o l’altro costruttore –dall’esterno si vedono solo i costruttori dei sottotipi –gli oggetti dei sottotipi vengono dall’esterno tutti visti come oggetti dell’unico supertipo (la specifica e’ uguale)

5 IntList 4 vogliamo dare implementazioni “alternative” 4 alcune operazioni possono essere comuni alle implementazioni –IntList è una classe astratta e non un interfaccia

6 Specifica della classe astratta –la classe astratta ha alcuni metodi non astratti comuni alle sottoclassi definiti in termini dei metodi astratti –la classe astratta non ha variabili di istanza e quindi nemmeno costruttori –E’ simile a quella vista, solo che il tipo e’ non modificabile

7 Cosa vuol dire? 4 Non ci sono metodi modificatori 4 I metodi che “modificano” la lista devono essere trasformati in produttori; ritornano una lista modificata, invece di modificare this 4 Esempi: addEl, first, rest

8 Specifica del supertipo IntList public abstract class IntList { // OVERVIEW: un IntList è una lista // non modificabile di Integers. // Elemento tipico [x1,...,xn] //metodi astratti public abstract Integer first () throws EmptyException; // EFFECTS: se this è vuoto solleva // EmptyException, altrimenti // ritorna il primo elemento di this public abstract IntList rest () throws EmptyException; // EFFECTS: se this è vuoto solleva // EmptyException, altrimenti // ritorna la lista ottenuta da this togliendo // il primo elemento

9 Specifica del supertipo IntList public abstract Iterator elements (); // EFFECTS: ritorna un generatore che produrrà // tutti gli elementi di this (come Integers) // nell’ordine che hanno in this public abstract IntList addEl (Integer x); // EFFECTS: ritorna una lista ottenuta // aggiungendo x all’inizio di this

10 Specifica del supertipo IntList public abstract int size (); // EFFECTS: ritorna il numero di elementi di this public abstract boolean repOk ();

11 Implementazione del supertipo IntList // metodi concreti public String toString () {....} public boolean equals (Object o) { //EFFECTS: verifica se this ed o sono la stessa lista } 4 vanno implementati sono metodi concreti 4 Si possono implementare usando il generatore elements (astratto) 4 Si ottiene una implementazione comune per tutti i possibili sottotipi

12 Implementazione 4 Non ci sono variabili d’istanza e costruttori 4 Vanno implementati solo i metodi concreti

13 ToString() public String toString () { Iterator g=elements(); String s=“”; while (g.hasnext()) { Integer el=(Integer) g.next(); s=s + el.intValue();} return s; } 4 Usando il generatore possiamo leggere la lista senza sapere come e’implementata (addirittura non e’ ancora implementata) 4 Meccanismo di iterazione astratta 4 Alternativa: si potrebbero usare first() e rest()

14 Equals() public boolean equals (Object o) { //EFFECTS: verifica se this ed o sono //la stessa lista } 4 Metodo sovrascritto da Object 4 Quello ereditato e’ poco utile perche’ verifica se il riferimento e’ lo stesso; vorremmo invece vedere se hanno gli stessi elementi

15 equals() public boolean equals (Object o) { IntList l= (IntList) o; if (! size()= l.size()) {return false;} if (size()==0 && l.size()==0) {return true;} else {Iterator g=elements(); Iterator h=l.elements(); while (g.hasnext()) { Integer el1=(Integer) g.next(); Integer el2=(Integer) h.next(); if ( ! el1.equals (el2)) {return false;} } return true;}}

16 IntList :sottoclassi 4 Le sottoclassi definiscono implementazioni “alternative”: ne vediamo per esempio due 4 Una è quella che abbiamo visto –ogni oggetto ha 4 campi (ne basterebbero 3) solo alcuni di questi sono utilizzati nei vari casi della definizione e ricorsiva

17 Prima Implementazione 4 Implementazione vista con la lista concatenata class IntListUno extends IntList{ private boolean vuota; private Integer val; private IntList next; private int sz; 4 Definizione ricorsiva: caso base la lista vuota (rappresentata tramite la variabile booleana vuota)

18 Rappresentazione Lista val next vuota Lista vuota: any true Lista non vuota: any true 154 false 24 false

19 Commenti 4 Vantaggio: definizione ricorsiva pulita, caso base: lista vuota 4 Svantaggio dell’implementazione: ogni lista vuota o non vuota ha 4 variabili d’istanza (ne bastano tre) 4 Nei metodi sono necessari continui test su “vuota” per distinguere i due casi

20 Implementazione alternativa 4 usiamo due sottotipi differenti per implementare i due casi della definizione ricorsiva –lista vuota –lista non vuota –Piu’ efficiente, occupa meno spazio, meno test necessari –Unisce i vantaggi delle due implementazioni viste in precedenza

21 4 Implementa il caso della lista vuota 4 Non ha variabili d’istanza (e quindi neanche invariante) 4 Dobbiamo fornire i costruttori e l’implementazione dei metodi astratti di IntList Implementazione del sottotipo EmptyIntList

22 4 Presentiamo la specifica insieme all’implementazione, direttamente 4 La specifica e’ leggermente diversa da quella del supertipo (le parti non riportate sono uguali) 4 Infatti e’ specializzata al caso della lista vuota Implementazione del sottotipo EmptyIntList

23 Implementazione del sottotipo EmptyIntList public class EmptyIntList extends IntList { // OVERVIEW: un EmptyIntList è una lista di Integers vuota. Elemento tipico [] public EmptyIntList () {} Non ha variabili d’istanza!

24 Implementazione del sottotipo EmptyIntList public Integer first () throws EmptyException // EFFECTS: solleva EmptyException { throw new EmptyException ("EmptyIntList.first"); } public IntList rest () throws EmptyException // EFFECTS: solleva EmptyException { throw new EmptyException ("EmptyIntList.rest"); } Sono specializzati per il caso della lista vuota!!!!

25 Implementazione del sottotipo Empty IntList public Iterator elements () {return new EmptyGen()} public IntList addEl (Integer x) {FullIntList n = new FullIntList(x); return n; } public int size () {return 0;} public boolean repOk () {return true;} Deve essere chiamato il costruttore dell’altro sottotipo quando si aggiunge un elemento

26 Implementazione del sottotipo Empty IntList static private class EmptyGen implements Iterator { EmptyGen () {} public boolean hasNext () { return false; } public Object next () throws NoSuchElementException {throw new NoSuchElementException("IntList.elements"); } } public abstract Iterator elements (){ // EFFECTS: ritorna un generatore che produrrà // tutti gli elementi di this (come Integers) // nell’ordine che hanno in this return new EmptyGen();}

27 Invariante e funzione di astrazione 4 Invariante non c’e’ (non ci sono variabili d’istanza) 4 Funzione di astrazione (rappresenta la lista vuota)  EmptyntList (c) = 

28 Implementazione del sottotipo FullIntList public class FullIntList extends IntList { // OVERVIEW: un FullIntList è una lista di Integers // non vuota. Elemento tipico [x1, …,xn] n>0 private Integer val; valore private IntList next; resto della lista private int sz; numero di elementi 4 Implementazione ricorsiva (e’ non vuota, non serve la variabile booleana) 4 sz variabile ausiliaria per contare il numero di elementi

29 Invariante e f. di astrazione I FullIntlist (c) = (c.next != null e c.sz= 1 + c.next.size() e c.next e’ EmptyIntList o I FullIntlist (c.next) )  (c) = [c.val] +  (c.next) 4 Le condizioni si separano e dividono nei due casi

30 Implementazione del sottotipo FullIntList public FullIntList (Integer x) // EFFECTS: inizializza this alla lista che contiene x {sz=1; val=x; next=EmptyIntlist();} public Integer first () throws EmptyException // EFFECTS: ritorna il primo elemento della lista {return val; } public IntList rest () throws EmptyException // EFFECTS: ritorna il resto della lista { return next; } 4 Non ci sono piu’ da fare test, in questo caso di sicuro val e next sono definiti (vedi anche l’invariante)

31 Implementazione del sottotipo Full IntList public Iterator elements () {return new FullGen(this)} public IntList addEl (Integer x) {FullIntList n = new FullIntList(x); n.next=this;n.sz=this.sz+1; return n; } public int size () {return sz;} public boolean repOk () {……..} 4 Omettiamo la definizione del generatore; pensate voi a come adattarlo

32 Vantaggi 4 I metodi per i due casi (lista vuota e non vuota) sono implementati in modo più efficiente 4 Si evitano tutta una serie di test per distinguere i due casi (il metodo più specifico viene chiamato automaticamente) 4 Anche dal punto di vista della correttezza e’ piu’ facile ragionare sui due casi separamente (si semplificano l’invariante e la funzione di astrazione)

33 Cosa cambia dal punto di vista dell’utente del tipo di dato? 4 Puo’ scegliere l’implementazione piu’ efficiente (scegliendo l’opportuno costruttore) 4 Siamo sicuri che tutti i sottotipi della classe astratta si comportano nello stesso modo? 4 Sarebbe ovviamente vero se tutti i sottotipi avessero per ogni metodo esattamente le stesse specifiche (ma…)

34 Differenza tra le specifiche 4 Abbiamo visto che gli oggetti del tipo FullIntList differiscono da quelli del supertipo (vedi OVERVIEW)  Anche le postcondizioni di alcuni metodi (es. first, rest)  Analogo per EmptyIntList 4 Ma esiste una relazione particolare tra specifiche del supertipo e del sottotipo

35 Prima proprieta’:dati 4 Le proprieta’ dei dati del supertipo sono piu’ generali di quelle dei sottotipi 4 Una lista non vuota e’ un tipo particolare di lista 4 Una lista vuota e’ un tipo particolare di lista 4 In conclusione, i dati del sottotipo soddisfano anche le richieste del supertipo

36 Seconda proprieta’:metodi 4 Le specifiche dei metodi (p.e. first) del supertipo e di quelli dei sottotipi richiedono lo stesso risultato per la lista vuota o non vuota rispettivamente 4 Le specifiche dei metodi del sottotipo non differiscono da quelle del supertipo, sono solo specializzate sui due casi rappresentati dai due sottotipi, lista vuota e non vuota

37 Esempio //metodo del supertipo public abstract Integer first () throws EmptyException; // EFFECTS: se this è vuoto solleva // EmptyException, altrimenti // ritorna il primo elemento di this //metodo del sottotipo Full public Integer first () throws EmptyException // EFFECTS: ritorna il primo elemento della lista 4 Quando viene selezionato quello del sottotipo, la lista e’ non vuota, il comportamento richiesto e’ esattamente quello del supertipo

38 Di conseguenza  Vuol dire che un programma scritto in termini del supertipo IntList lavora correttamente su oggetti del sottotipo FullIntList o EmptyIntList 4 Vale il Principio di sostituzione: un oggetto del sottotipo può essere sostituito ad un oggetto del supertipo senza influire sul comportamento dei programmi che utilizzano il tipo

39 Esempio 4 Supponiamo di avere un metodo statico che e’ scritto guardando la specifica del supertipo IntList public static boolean cerca (Intlist l,Integer x) throws NullPointerException { // EFFECTS: se l o x sono null solleva // NullPointerException, altrimenti restituisce // true se x occorre nella lista l, false se // non occorre}

40 Implementazione public static boolean cerca(Intlist l,Integer x) throws NullPointerException { if (x==null|| l==null) throw new NullPointerException(“Lista.cerca”); if (l.size()==0) {return false;} else {Integer el=l.first(); if (el.equals(x)) {return true;} return cerca(l.rest(),x);} }

41 Principio di Sostituzione 4 I metodi dei due sottotipi garantiscono lo stesso comportamento di quelli di IntList 4 Di conseguenza cerca puo’ essere utilizzato sia con un parametro di tipo FullIntList che EmptyIntList 4 Inoltre per provarne la correttezza e’ sufficiente avere considerato le specifiche di IntList

42 Principio di Sostituzione 4 Deve essere sempre cosi’ altrimenti il meccanismo di fattorizzazione offerto dall’ereditarieta’ servirebbe a poco 4 Bisogna garantire la modularita’ ovvero che la definizione di sottotipi non richieda di dimostrare da capo la correttezza di tutto il codice corretto rispetto al supertipo

43 Principio di sostituzione 4 Non vale sempre in generale  Quale deve essere la relazione tra le specifiche del sottotipo e del supertipo? 4 Perche’ valga il sottotipo deve soddisfare le specifiche del supertipo 4 Cosa vuol dire? 4 Cosa succede se non vale?

44 Intuitivamente 4 La specifica del sottotipo deve implicare quella del supertipo 4 Proprieta’ dei dati (OVERVIEW) 4 Proprieta’ dei metodi riscritti –se la specifica nel supertipo è nondeterministica (ammette varie possibilità) il sottotipo può avere una specifica più forte che risolve (in parte) il nondeterminismo

45 Esempio 4 SortedIntSet (insiemi ordinati) sottotipo di IntSet (insiemi non ordinati) public class IntSet { public Iterator elements () // EFFECTS: ritorna un generatore che produrrà tutti gli elementi di // this (come Integers) ciascuno una sola volta, in ordine arbitrario 4 il metodo elements di SortedIntSet assume l’ordine crescente public class SortedIntSet { public Iterator elements () // EFFECTS: ritorna un generatore che produrrà tutti gli elementi di // this (come Integers) ciascuno una sola volta, in ordine crescente

46 Vale il principio di sostituzione 4 Specifica del sottotipo e’ piu’ forte, implica anche le proprieta’ del supertipo 4 Per i dati: un insieme ordinato e’ anche un insieme 4 Il generatore che restituisce gli elementi in ordine e’ un caso particolare di quello che lo restituisce in qualsiasi ordine

47 Di conseguenza  I programmi provati corretti rispetto alla specifica di IntSet funzionano correttamente anche per il sottotipo SortedIntSet 4 Vediamo un esempio

48 Procedura per l’uguaglianza public static boolean uguali(IntSet x,IntSet y){ // EFFECTS: verifica se x ed y hanno gli stessi elementi {{if (x == null || y==null) return false; Iterator g=x.elements(); while (g.hasnext()) {int temp=( (Integer) g.next()).intValue(); if (!y.isIn(temp)) {return false;} } Iterator g=y.elements(); while (g.hasnext()) {int temp=( (Integer) g.next()).intValue(); if (!x.isIn(temp)) {return false;} } return true;}

49 Procedura per l’uguaglianza 4 Scritta guardando la specifica di IntSet 4 Siccome non sono ordinati deve generare tutti gli elementi di x e di y 4 La procedura uguale e’ corretta rispetto alla specifica del supertipo IntSet

50 Commenti 4 Dato che vale il p. di sostituzione e’ corretta anche se chiamata con parametri del sottotipo SortedIntSet 4 In tal caso il generatore e’ quello del sottotipo e genera i valori in modo ordinato (tutto continua a funzionare)

51 Vantaggio 4 Non dobbiamo ridimostrare la correttezza del metodo uguali per il sottotipo SortedIntSet 4 La correttezza del sottotipo (pr. Di sostituzione) garantisce che valga 4 Sarebbe impensabile dover ripetere tutte le dimostrazioni per ogni sottotipo

52 Cosa succede se non vale? 4 Se non vale il principio di sostituzione programmi dimostrati corretti rispetto alla specifica del supertipo potrebbero non esserlo quando si usa il sottotipo 4 Dovrei ridimostrare la loro correttezza rispetto alle specifiche di tutti i sottotipi 4 Sconsigliato: vuol dire che non sono ben definiti (perdo la flessibilita’ dell’uso dei sottotipi)

53 Esempio 4 Se ammettessi di definire IntSet come sottotipo di SortedIntSet 4 Non vale il principio di sostituzione: il sottotipo soddisfa proprieta’ piu’ deboli 4 Un insieme in cui gli elementi sono messi in modo arbitrario non e’ ordinato (analogo per il generatore)

54 Procedura che verifica l’uguaglianza (per SortedIntset) public static boolean uguali(SortedIntSet x,SortedIntSet y){ // EFFECTS: verifica se x ed y hanno gli stessi elementi {{if (x == null || y==null) return false; Iterator g=x.elements(); Iterator h=y.elements(); while (g.hasnext() & & h.hasnext()) {int temp1=( (Integer) g.next()).intValue(); int temp2=( (Integer) h.next()).intValue(); if (!temp1.equals (temp2)) {return false;} } if (! (g.hasnext() | | h.hasnext())) {return true;} else {return false;} }

55 Procedura che calcola l’uguaglianza 4 Corretta rispetto alla specifica del supertipo 4 Sfrutta le caratteristiche del supertipo ovvero l’ordinamento (piu’ efficiente) 4 Se chiamata con parametri del sottotipo IntSet (in tal caso non funziona correttamente)

56 Dove sta l’errore? 4 Il sottotipo non ordinato non e’ un sottotipo corretto di ordinato 4 Il principio di sostituzione non vale 4 Il principio di sostituzione e’ fondamentale per riutilizzare il codice

57 Principio di sostituzione 4 Perche’ valga in generale bisogna verificare che –la regola delle proprietà il sottotipo deve preservare tutte le proprietà che valgono sugli oggetti del supertipo –la regola dei metodi le chiamate dei metodi del sottotipo devono comportarsi come le chiamate dei corrispondenti metodi del supertipo 4 tutte le regole riguardano solo le specifiche di supertipo e sottotipo

58 Regola dei metodi 1 4 le chiamate dei metodi del sottotipo devono comportarsi come le chiamate dei corrispondenti metodi del supertipo 4 va bene se i metodi overriden del sottotipo hanno esattamente le stesse specifiche di quelli del supertipo 4 Possono essere diverse se la specifica dei metodi del sottotipo e’ piu’ forte –Come nell’esempio del generatore visto prima

59 Regola dei metodi 3 4 Per formalizzare bene il concetto di specifica più forte bisogna considerare –La precondizione (specificata dalla clausola REQUIRES) definisce i vincoli sugli inputs –La postcondizione (specificata dalla clausola EFFECTS) definisce le proprietà che valgono dopo l’esecuzione del metodo sugli inputs che soddisfano la precondizione

60 Regola dei metodi 4 4 in generale un sottotipo può indebolire le precondizioni e rafforzare le post condizioni 4 per avere compatibilità tra le specifiche del supertipo e quelle del sottotipo devono essere soddisfatte le regole –regola delle precondizione pre super ==> pre sub –regola delle postcondizione pre super && post sub ==> post super

61 Regola dei metodi 4 4 indebolire la precondizione –pre super ==> pre sub ha senso, perché il codice che utilizza il metodo è scritto per usare il supertipo –ne verifica la precondizione –verifica anche la precondizione del metodo del sottotipo 4 esempio: un metodo in IntSet public void addZero ( ) // REQUIRES: this non è vuoto // EFFECTS: aggiunge 0 a this potrebbe essere ridefinito in un sottotipo public void addZero ( ) // EFFECTS: aggiunge 0 a this

62 Regola dei metodi 5 4 rafforzare la post condizione –pre super && post sub ==> post super ha senso, perché il codice che utilizza il metodo è scritto per usare il supertipo –È soddisfatta la precondizione più forte (quella del supertipo) –gli effetti del metodo del sottotipo includono comunque quelli del supertipo (se la chiamata soddisfa la precondizione più forte) 4 esempio: un metodo in IntSet public void addZero ( ) // REQUIRES: this non è vuoto // EFFECTS: aggiunge 0 a this potrebbe essere ridefinito in un sottotipo public void addZero ( ) // EFFECTS: se this non è vuoto aggiunge 0 a this altrimenti aggiunge 1 a this

63 Regola dei metodi 6 public class IntSet { public Iterator elements () // EFFECTS: ritorna un generatore che produrrà tutti gli elementi di // this (come Integers) ciascuno una sola volta, in ordine arbitrario public class SortedIntSet extends IntSet { public Iterator elements () // EFFECTS: ritorna un generatore che produrrà tutti gli elementi di // this (come Integers) ciascuno una sola volta, in ordine crescente 4 entrambi i metodi hanno precondizione true 4 la postcondizione del metodo del sottotipo –gli elementi sono generati in ordine crescente implica la postcondizione del metodo del supertipo

64 Regola dei metodi: violazioni 1 4 consideriamo insert in IntSet public class IntSet { public void insert (int x) // MODIFIES: this // EFFECTS: aggiunge x a this 4 supponiamo di definire un sottotipo di IntSet con la seguente specifica di insert public class StupidoIntSet extends IntSet { public void insert (int x) // MODIFIES: this // EFFECTS: aggiunge x a this se x è pari, altrimenti non fa nulla 4 La postcondizione è stata indebolita (errore) 4 Chi usa insert si aspetta che x venga aggiunto comunque! 4 Se vogliamo un metodo di questo tipo nel sottotipo perche’ chiamarlo uguale esovrascriverlo?

65 Regola dei metodi: violazioni 2 4 consideriamo addEl in OrderedIntList public class OrderedIntList { public void addEl (int x) throws DuplicateException { // MODIFIES: this // EFFECTS: aggiunge x a this se non c’è già, altrimenti solleva l’eccezione 4 supponiamo di definire un sottotipo di OrderedIntList con la seguente specifica di addEl public void addEl (int x) // MODIFIES: this // EFFECTS: aggiunge x a this 4 non è un problema la differenza della segnatura 4 ma c’è un problema con la regola dei metodi –se l’elemento c’è già, i due metodi hanno comportamento diverso –e quello del sottotipo fa “meno cose” (è più debole)

66 Regola delle proprietà 4 il ragionamento sulle proprietà degli oggetti basato sul supertipo è ancora valido quando gli oggetti appartengono al sottotipo 4 proprietà degli oggetti astratti –non proprietà dei metodi 4 da dove vengono le proprietà degli oggetti? –dal modello del tipo di dato astratto le proprietà degli insiemi matematici, etc. le elenchiamo esplicitamente nell’overview del supertipo 4 Un insieme ordinato e’ anche un insieme