Subtype Polymorphism

• Interfacce e subtype polimorfismo Tipi, sottotipi e conversioni di tipo Polimorfismo e dinamic dispatch

Conversioni di tipo

• Variabile: locazione con un tipo associato Tipo della variabile determinato dal compilatore

guardando la dichiarazione Una variabile di tipo reference contiene un riferimento

ad un oggetto

• Oggetto: istanza di una classe Tipo dell’oggetto: la classe che lo crea Determinato a run time

• Una variabile può assumere come valori riferimenti ad oggetti di classi diverse

Continua…

Conversioni di tipo

• È possibile assegnare un riferimento di tipo classe ad una variabile di tipo interfaccia purchè la classe implementi l’interfaccia

BankAccount account = new BankAccount(10000);Measurable x = account; // OK

Coin dime = new Coin(0.1, "dime");Measurable y = dime; // OK

Continua…

Conversioni di tipo

• La conversione è lecita solo in determinate situazioni

• Problema: Rectangle non implementa Measurable

Measurable x = new Rectangle(5, 10, 20, 30); // ERRORE

Subtyping

• Subtyping (<:) Una relazione che permette di decidere quando è

legittimo convertire un tipo riferimento in un altro

• Chi decide cosa/quando è legittimo? il compilatore!

• Per il momento la regola è:

Continua…

T1 <: T2 sse T1 è una classe, T2 è una interfaccia T1 implementa T2.

Subtyping

• Principio di sostituibilità Un riferimento di un sottotipo può essere usato

ovunque ci si aspetti un riferimento di un supertipo

• Le regole di sottotipo devono garantire la correttezza del principio di sostituibilità

Continua…

Subtyping

• La regola C <: I se C implementa I

• Principio di sostituibilità un riferimento di tipo C può sempre essere usato dove

si attende un riferimento di tipo I

• E’ ragionevole perché se C implementa I , C definisce public tutti i metodi

dichiarati da I Quindi tutti le invocazioni di metodo possibili per I sono

supportate da C

Continua…

Subtyping e regole di typing

• Regola di assegnamento Un riferimento di tipo T1 si puo sempre assegnare ad una variabile

di tipo T2 sse T1 <: T2 Un riferimento di tipo classe può sempre essere assegnato ad una

variabile di tipo interfaccia (se la classe implementa l’interfaccia)

• Regola di passaggio di parametri Un riferimento di tipo T1 si puo sempre passare per un parametro

di tipo T2 sse T1 <: T2 Un riferimento di tipo classe può sempre essere passato per un

parametro di tipo interfaccia (se la classe implementa l’interfaccia)

Domanda

• Data l’implementazione generica della classe DataSet, che oggetti possiamo passare come argomento per x ?

public class DataSet { public void add(Measurable x) { ... }

... }

Risposta

• Qualunque istanza di una una classe che implementa Measurable

Polimorfismo – dynamic dispatch

• Una variabile di tipo interfaccia ha sempre come valore un riferimento di una classe che implementa l’interfaccia

Continua…

Measurable x;x = new BankAccount(10000);x = new Coin(0.1, "dime");

Polimorfismo – dynamic dispatch

• Possiamo invocare ognuno dei metodi dell’interfaccia:

• Quale metodo invoca?

double m = x.getMeasure();

Polimorfismo – dynamic dispatch

• Dipende dal riferimento corrente memorizzato nella variabile 

• Se x riferisce un BankAccount, invoca il metodo BankAccount.getMeasure()

• Se x riferisce un Coin, invoca il metodo Coin.getMeasure()

• Polimorfismo (molte forme): il comportamento varia, e dipende dal tipo dinamico

della variabile

Continua…

Domande

5. È impossibile costruire un oggetto di tipo Measurable.Perché?

6. Perché invece é possibile dichiarare una variabile di tipo Measurable?

Risposte

5. Measurable è una interfaccia. Le interfacce non hanno campi o implementazione di metodo.

6. Perché Measurable è un tipo: la variabile non riferirà mai una istanza di Measurable, (le interfacce non hanno istanze) ma piuttosto oggetto di una qualche classe che implementa l’interfaccia Measurable.

Continua…

• Costruiamo una applicazione per disegnare un insieme di forme geometriche contenute in una componente grafico: definiamo GWin, una classe che descrive un

contenitore di forme geometriche disegnate mediante una invocazione del metodo paint()

per esemplificare, consideriamo due tipi di forme: Car e Smiley

Ancora un esempio

Forme grafiche

class Car{ . . . public void draw(Graphics2D g) { // Istruzioni per il disegno . . . }} class Smiley

{ . . . public void draw(Graphics2D g) { // Istruzioni per il disegno . . . }}

• Un contenitore di Cars e Smileys

GWin

/** Una finestra che contiene un insieme Cars e Smileys */ class GWin { /** Disegna tutte le forme di questo component */ public void paint(){ /* disegna su g */ } /**

Componente grafica su cui disegnare */

private Graphics2D g; }

Domanda

• Che struttura utilizziamo per memorizzare le forme contenute nella GWin?

• Come definiamo il metodo paint() in modo che disegni tutte le forme della componente?

Risposte

• definiamo una nuova interfaccia: Shape

• Ridefiniamo le classi Car e Smiley in modo che implementino Shape

• Memorizziamo gli oggetti della componente in una ArrayList<Shape>

interface Shape { void draw(Graphics2D g); }

Car e Smiley implementano Shape

class Car implements Shape

{ . . . public void draw(Graphics2D g) { // Istruzioni per il disegno . . . }} class Smiley implements Shape

{ . . . public void draw(Graphics2D g) { // Istruzioni per il disegno . . . }}

Mantiene una ArrayList<Shape>

GWin

class GWin { private Graphics2D g; private ArrayList<Shape> shapes; // crea una GWin con un insieme di forme public GWin(Shape... shapes) { Graphics2D g = new Graphics2D();

this.shapes = new ArrayList<Shape>(); for (Shape s:shapes) this.shapes.add(s); } // disegna tutte le componenti della GWin public void paint() {

for (Shape s:shapes) s.draw(g); } }

Diagramma delle Classi

Car

GWin

Smiley

Shape

Car

So long, for today

Polimorfismo – dynamic dispatch

• Dynamic dispatch: Il metodo da invocare per rispondere ad un

messaggio è deciso a tempo di esecuzione

Dynamic dispatch in GWin

class GWin { . . . private ArrayList<Shape> shapes; . . . public void paint() {

// disegna tutte le componenti della GWin // il metodo invocato effettivamente da ogni

// messaggio s.draw(g) dipende dalla classe // di cui s è istanza ed è deciso a runtime

for (Shape s:shapes) s.draw(g); } . . . . }

Dynamic dispatch vs overloading

• Dynamic dispatch: Il metodo da invocare per rispondere ad un

messaggio è deciso a tempo di esecuzione

• Notiamo bene Il metodo da invocare è deciso a runtime il compilatore decide se esiste un metodo da invocare

• Overloading: Nel caso esista più di un metodo, il compilatore

decide staticamente il tipo del metodo da invocare

Dynamic dispatch vs overloading

interface I { public String m(boolean b); public String m(double d); } class A implements I { public String m(boolean b) { return “A.m(boolean)”; } public String m(double d) { return “A.m(double)”; } }

class B implements I { public String m(boolean b) { return “B.m(boolean)”; } public String m(double d) { return “B.m(double)”; } }

Dynamic dispatch vs overloading

class Client { public void static show(I x) { // tipo del metodo invocato = m(boolean) // deciso dal compilatore staticamente // metodo invocato deciso dinamicamente // in funzione del tipo dell’argomento // passato per x

System.out.println( x.m(false) ); } }

Domanda

• Che cosa hanno in comune i meccanismi di overloading e di dynamic dispatch? In cosa sono diversi?

• Entrambi i meccanismi contribuiscono a decidono quale metodo eseguire in risposta ad un messaggio, ma• Nell’overloading scelta è relativa al tipo del metodo,

ed è fatta in compilazione guardando il tipo dei parametri

• Nel dynamic dispatch la scelta è relativa al corpo del metodo, ed è fatta in esecuzione guardando il tipo dell’oggetto che riceve il messaggio

Risposta

Subtyping e sostituibilità

• Principio di sostituibilità Un riferimento di un sottotipo può essere usato

ovunque ci si aspetti un riferimento di un supertipo

• Le regole di sottotipo garantiscono la correttezza del principio di sostituibilità Tutti i metodi del supertipo devono essere

implementati dal sottotipo Il sottotipi può avere anche altri metodi

Continua…

Subtyping e perdita di informazione

• Principio di sostituibilità Un riferimento di un sottotipo può essere usato

ovunque ci si aspetti un riferimento di un supertipo

• Può causare perdita di informazione nel contesto in cui ci aspettiamo il supertipo, non

possiamo usare solo I metodi del supertipo perdiamo la possibilità di utilizzare gli eventuali metodi

aggiuntivi del sottotipo

Continua…

Car e Smiley implementano Shape

class Smiley implements Shape

{ . . .public void draw(Graphics2D g){ . . . }public String mood() {. . . }

}

class Car implements Shape

{ . . .public void draw(Graphics2D g){ . . . }public String brand() {. . . }

}

Subtyping e perdita di informazione

• Consideriamo

public static void printBrand(List<Shape> l)

{ for (Shape s : l)

// stampa la marca di tutte le macchine di l

// ???

}

Continua…

Subtyping e perdita di informazione

• Certamente non possiamo fare così …

public static void printBrand(List<Shape> l)

{ for (Shape s : l)

// stampa la marca di tutte le macchine di l

System.out.println( s.brand() ); // TYPE ERROR!

}

Continua…

Cast

• Permette di modificare il tipo associato ad una espressione

• Un cast è permesso dal compilatore solo se applica conversioni tra tipi compatibili

• Compatibili = sottotipi (per il momento)

• Anche quando permesso dal compilatore, un cast può causare errore a run time

• Se s non è un Car errore a run time

Continua…

((Car)s).brand()

Cast

• Tipo statico e tipo dinamico di una variabile tipo statico: quello dichiarato tipo dinamico: il tipo del riferimento assegnato alla

variabile

• (T)var causa errore in compilazione

se T non è compatibile con il tipo statico di var in esecuzione (ClassCastException)

se T non è compatibile con il tipo dinamico di var

Continua…

Cast

• OK: Car sottotipo di Shape

• Compila correttamente il tipo dichiarato di s è Shape Car e Shape sono compatibili

• Esegue correttamente s è un Car (il tipo dinamico di s è Car)

Shape s = new Car();

Continua…

Car c = (Car) s

Cast

• OK: Car sottotipo di Shape

• Compila correttamente il tipo dichiarato di s è Shape Smiley e Shape sono compatibili

• Errore a run time s non è uno Smiley

Shape s = new Car();

Continua…

Smiley c = (Smiley) s

Cast

• Attenzione anche qui …

public static void printBrand(List<Shape> l)

{ for (Shape s : l)

// ClassCastException se s instance of Smiley

System.out.println( ((Car)s.)brand() );

}

Continua…

instanceof

• Permette di determinare il tipo dinamico di una variabile

• Quindi permette di evitare errori in esecuzione

• Esegue correttamente, perchè x è sicuramente un T

x istanceof T è true solo se x ha tipo dinamico T

if (x instanceof T) return (T) x

Cast

• Questo, finalmente, è corretto

public static void printBrand(List<Shape> l)

{ for (Shape s : l)

if (s instanceof Car)

System.out.println( ((Car)s.)brand() );

}

Domanda

• E se volessimo disegnare solo le Shapes che sono Cars?

Risposta

// disegna tutte le Cars della GWin

public void paint(){ for (Shape c:shapes)

if (c instanceof Car) c.draw(g); }