Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D

Transcript

1 + Sviluppo Applicazioni Mobile Lezione 11

2 + Credits I lucidi di questa lezione sono stati preparati da: Professor Stefano Mizzaro Professor Paolo Coppola e sono stati modificati e completati dal Dr. Paolo Casoto nel Sono rilasciati con licenza Creative Commons Attribuzione, non commerciale e non opere derivate.

3 + Cosa vediamo nella lezione di oggi Approfondiamo le tematiche di ereditarietà e polimorfismo analizzando nello specifico il caso dei costrutti messi a disposizione da Java. In particolare proseguiremo nel nostro percorso: Incapsulamento: creare nuovi tipi di dato combinando attributi ed operazioni (o caratteristiche e comportamenti, seguendo la definizione di B. Eckel). Occultamento dell implementazione: rendo privati i dettagli delle mie classi, accessibili solo mediante una interfaccia pubblica Ereditarietà: consente di rappresentare un oggetto come istanza di molteplici tipi, organizzati all interno di una gerarchia. Polimorfismo: consente di differenziare il comportamento di oggetti istanza di classi che derivano da una sovraclasse comune.

4 + Un caso particolare di polimorfismo Consideriamo il caso seguente: La classe A, classe base, all interno del suo costruttore invoca il proprio metodo metodo1 La classe B estende da A. Ciò comporta che ad ogni invocazione de costruttore di B sia eseguita, per prima, l invocazione del relativo costruttore di A. La classe B sovrascrive il metodo metodo1 ereditato da A Domanda: quale versione del metodo metodo1 sarà invocata dal costruttore di A quando istanzio un nuovo oggetto della classe B? Quello di A o quello di B? Ma gli attributi propri di B non sono ancora stati allocati, come posso utilizzarli? Risposta: viene eseguito il metodo della classe B con eventuale lancio di eccezioni!!!

5 + Su quali metodi non posso applicare il polimorfismo? Tutti i metodi di istanza con modificatore private Tutto ciò che è private è anche final e soggetto a binding a tempo di compilazione. Il tutto è abbastanza logico non posso ridefinire quello che non vedo Se in una sottoclasse B definisco un metodo public con la stessa firma di un metodo private della classe base A funziona ma non è un overriding, semplicemente sono due metodi differenti. I metodi statici solo relativi alle classi e non agli oggetti e non sono soggetti a polimorfismo. Se effettuo un upcasting ed invoco un metodo statico p presente sia nella sovraclasse A sia nella sottoclasse B, sarà eseguito il metodo A.p()

6 + Riprendiamo l esempio geometrico Gerarchia di figure con metodo polimorfico draw()

7 + Figura con area()? Aggiungiamo un metodo area() alla gerarchia Ma come calcolare l area di una figura generica? Quadrati, cerchi e punti lo sanno fare Cerchio c = new Cerchio(); Figura f = new Cerchio(); System.out.println(c.area()); System.out.println(f.area());

8 + Figura senza area()? Una figura generica non sa calcolare la propria area. Quindi niente area() in Figura! Ma se non metto area() in Figura Cerchio c = new Cerchio(); Figura c1 = new Cerchio(); Figura f = new Figura(); System.out.println(c.area()); System.out.println(f.area()); System.out.println(c1.area()); cannot resolve symbol symbol : method area () location: class Figura f.area(); ^

9 + Problema: Figura e area() Se metto area() in Figura Non so cosa deve fare Se non metto area() in Figura No polimorfismo, perché non posso essere sicuro che le istanze di Figura (o sottoclasse) hanno area() Soluzione: classi e metodi astratti

10 + Figura e area() astratti Soluzione: area() in Figura è astratto (non invocabile) anche Figura è astratta (non istanziabile) Astratto (metodo o classe) = non completamente specificato Figura funge da idea, da protocollo, ma non fornisce una implementazione reale

11 + In Java abstract Se class dichiaro Figura{ abstract double area(); } erchio c = new Cerchio(); igura poi f = posso new scrivere Cerchio(); ystem.out.println(c.area()); ystem.out.println(f.area()); Ma non posso scrivere f = new Figura(); System.out.println(f.area()); System.out.println((Figura)c.area());

12 + Classi e metodi astratti 1/2 Una classe astratta non può essere istanziata Metodo astratto: metodo privo di implementazione, il cui corpo è sostituito da ; Se una classe contiene metodi astratti allora deve essere astratta ( Pensate a cosa succederebbe invocando un metodo astratto Non è detto che una classe astratta contenga esclusivamente metodi astratti Se una classe è astratta allora deve contenere metodi astratti

13 + Classi e metodi astratti 2/2 Grazie all introduzione delle classi astratte posso scomporre il mio problema ed avere una maggiore genericità. Alcune classi della mia gerarchia sono lasciate non specificate Posso specializzarne il comportamento nelle classi che le estendono Impedire la creazione di istanze di una classe Permette il polimorfismo Si può parlare alla classe base astratta In Java le classi astratte sono caratterizzate dal modificatore abstract, utilizzato anche per i metodi astratti. Non posso utilizzare abstract insieme a static (relativo a metodi ed attributi di classe), insieme a final ed insieme a private (altrimenti se nessuno lo vede chi lo implementa J )

14 + Curiosità Ma se voglio impedire che la mia classe sia estesa da qualche altra classe? Posso utilizzare il modificatore final, che ne impedisce l estensione. Tutti i metodi di una classe final sono, implicitamente, final. Ma se voglio impedire che un metodo della mia classe sia sovrascritto da qualche altra classe? Posso utilizzare il modificatore final, che ne impedisce l estensione. Come impedire che la mia classe sia istanziata? Dichiaro il costruttore private e vincolo l accesso alle istanze della classe ad un metodo statico. Pattern Singleton (Singoletto), utilizzato, ad esempio, nel caso di oggetti per i quali è necessario garantire l unicità E.g. spooler di stampa

15 + Interfacce Le interfacce portano il concetto di astrazione precedentemente descritto ai massimi termini. Una interfaccia non fornisce alcuna implementazione ed alcun attributo. Tutta l implementazione è a carico delle classe che implementa una interfaccia. Solo metodi di istanza astratti Eventuali campi statici e costanti In alcuni linguaggi sono anche descritte come protocolli (e.g. Objective C) Una classe A può implementare l interfaccia I: class A implements I {...} A definisce tutti i metodi di I

16 + Figure scalabili (1/3) interface Scalabile { public void riduci (int scala); } abstract class Figura {...//tutto come prima... } class Punto extends Figura {...//tutto come prima... }

17 + Figure scalabili (2/3) class Cerchio extends Figura implements Scalabile {...//tutto come prima... public void riduci (int scala) { raggio = raggio * scala / 100; } } class Quadrato extends Figura implements Scalabile {...//tutto come prima... public void riduci (int scala){... } }

18 + Figure scalabili (3/3) Scalabile s1 = new Quadrato(); Ora posso scrivere Scalabile s2 = new Cerchio(); s1.riduci(50); Scalabile[] s = new Scalabile[10];... s[i] = new Cerchio(); s[j] = new Quadrato();... s[i].riduci(50); s[j].riduci(20);

19 + Interfacce Oltre alle classi: interfacce Classi che implementano interfacce devono implementarne i metodi: se C implements I siamo sicuri (anche il compilatore!) che gli oggetti di C hanno i metodi di I (oppure C è astratta) abstract class NonSoComeRidurmi implements Scalabile{ // senza riduci() }

20 + Interfacce ed eredità Un interfaccia J può ereditare da un interfaccia I Una classe (non astratta) C che implementa J deve implementare i metodi anche di I

21 + Eredità singola e multipla Eredità singola Ogni classe è sottoclasse diretta di un unica superclasse Eredità multipla Le classi possono avere più superclassi dirette

22 + Eredità multipla: pro Gerarchie nel mondo reale: non sempre a eredità singola Cerchio sottoclasse di Figura Scalabile (oggetti che possono ridursi) Cerchio eredita i metodi sia di Figura sia di Scalabile

23 + e contro Se sia B sia C definiscono m() Da chi viene ereditato m()? Quale m() va eseguito alla chiamata x.m()?

24 + Eredità multipla in Java? Java: eredità singola Parimenti in C# C++: eredità multipla In Java l eredità multipla rientra dalla finestra grazie alle interfacce class A extends B, C {... }

25 + Eredità multipla con interfacce interface I1 {...} interface I2 {...} class C implements I1, I2 {... } interface I3 extends I1, I2 {} class D implements I3 {...}

26 + Eredità multipla con interfacce Quindi: Un interfaccia può estendere più interfacce Una classe può implementare più interfacce (interfacce!= classi astratte) Perché? No eredità multipla dell implementazione

27 + Utilità delle interfacce (1/3) Un altra possibilità per il polimorfismo Parlare alla classe base = interfaccia Es.: array di oggetti scalabili Scalabile[] s = new Scalabile[10]; s[i] = new Cerchio(); s[j] = new Quadrato();... s[i].riduci(50); s[j].riduci(20);

28 + Utilità delle interfacce (2/3) Definizione costanti Oltre a metodi d istanza astratti, anche attributi! Però static e final (ossia: costanti) Più comodo di CostantiUtili.PI interface CostantiUtili{ public static final double PI = ; public static final double E = ; } class C implements CostantiUtili{... PI... E... }

29 + Utilità delle interfacce (3/3) Marcatori di oggetti, per sapere se un oggetto è istanza di una classe che implementa un interfaccia Ad esempio la clonabilita è gestita con interface Cloneable { } Per vericare se una classe è clonabile: if (x instanceof Cloneable) {... operazioni di duplicazione... } else System.out.println("Non clonabile"); In maniera similare Java gestisce, ad esempio, la serializzazione degli oggetti su file.

30 + Utilità classi astratte - bis (1/2) Pattern comune: Classi astratte che forniscono implementazioni parziali o banali di un interfaccia Esempio: Classe C che deve implementare un interfaccia I con tanti metodi ma è interessata solo a uno di questi (gli altri vuoti) Se c è una classe adattatore Ne vedremo un esempio parlando di interfacce grafiche Java quando andremo a conoscere le classi WindowListener e WindowAdapter

31 + Utilità classi astratte - bis (2/2) interface I { public void m1(); public void m2();... public void mn(); } class C3 implements I { class public C2 void implements m1(){} I { class public C1 void implements m1(){} m2(){} I { public... void m1(){...} m2(){} public... public void void m2(){} mn(){...}... public } void mn(){...} public } void mn(){} } abstract class A implements I { public void m1(){} public void m2(){}... public void mn(){} } class Cn extends A { public void mn(){...} class } C2 extends A { public void m2(){...} class } C1 extends A { public void m1(){...} }

32 + Conversioni di tipo e cast Con i tipi predefiniti: Promozione (implicita): da byte ad int Cast (esplicito): da int a byte Con le classi Promozione (implicita): da B ad A Cast (esplicito): da A a B Implicito: non crea problemi A B

33 + Cast rivisitato: upcast Upcast/Promozione: Di solito implicita Ok perché non pericolosa Figura[] f = new Figura[ ]; f[i] = new Punto(); f[i] = (Figura)new Punto();

34 + Cast rivisitato: downcast Esplicito e pericoloso Se so che f[i] è un Punto, posso chiamare i suoi metodi, previo cast Ma se poi f[i] non è un Punto, errore in esecuzione A volte downcast non fino in fondo alla gerarchia (array di Object, contenente una Figura ) Figura[] f = new Figura[ ]; f[i] = new Punto(); f[j] = new Cerchio(); f[i].setx(2.0); f[j].setx(2.0); (Punto)f[i].setX(2.0); (Punto)f[j].setX(2.0);

35 + Classi interne Possibilità di definire una classe all interno di un altra classe Consente di raggruppare classi logicamente interconnesse in modo da poterne controllare la visibilità fra le stesse. La particolarità delle classi interne è quella di poter comunicare con la classe che la circonda senza dover ricorrere a lunghe catene di delega e riducendo la conascenza fra le classi stesse. E.g.: un oggetto A deve passare ad un altro oggetto B se stesso per consentire a B di modificarne le proprietà al verificarsi di un evento. Le classi interne includono un riferimento implicito alla classe esterna che le contiene. Posso allocare un oggetto di una classe interna solo a partire da un oggetto della classe esterna precedentemente inizializzato

36 + Classi interne Per ottenere il riferimento all oggetto della classe esterna dall interno di una classe interna è necessario utilizzare la sintassi: NomeDellaClasseEsterna.this Per creare un oggetto della classe interna da un terzo oggetto, dato il riferimento all oggetto della classe esterna b, devo utilizzare la sintassi: NomeDellaClasseEsterna. NomeDellaClasseInterna = b.new NomeDellaClasseInterna (); E.g.: Outer out = new Outer; Outer.Inner in = out.new Inner(); Con Outer classe esterna ed Inner definita al suo interno

37 + Classi interne E possibile definire anche classi interne con visibilità limitata all interno di un metodo della classe esterna o di un singolo blocco del metodo stesso. E possibile definire anche classi anonime, il cui corpo ed i cui metodi sono definiti al volo in fase di istanziazione dell oggetto. Si utilizza di solito per i gestori degli eventi associati alle componenti grafiche nelle GUI. Ove non sia necessario disporre di un legame fra classi interne ed esterne è possibile definire le cosiddette classi innestate: definite come static, non necessitano di un oggetto della classe esterna per essere istanziate. Non possono accedere in modo implicito alle proprietà di istanza della classe esterna Infatti non si mantiene un riferimento ad una istanza dell oggetto esterno

38 + Esempio class Classe { class Membro extends A {... } public void m() { class Locale extends A {... } Membro m = new Membro(); Locale l = new Locale(); A x = (new A(){... }); } } Anche se A è un interfaccia! (extends!= implements)

39 + Incapsulamento Abbiamo visto come l incapsulamento sia una delle proprietà principali che hanno portato alla programmazione OO Incapsulare in una unità separata elementi funzionali coerenti Incapsulamento su più livelli Livello 0: codice grezzo Livello 1: procedure, operazioni (programmazione strutturata) Livello 2: oggetti, costituiti da un insieme di proprietà ed operazioni coerenti e la cui implementazione può essere nascosta Livello 3: package o namespace Livello 4: componenti, moduli e ma non esageriamo per ora, limitiamoci ai primi 3 livelli.

40 + Metriche legate all incapsulamento Ventaglio: numero di riferimenti a procedure (L1) presenti all interno di una linea di codice (L0) Quanto la specifica linea di codice è dipendente da altre entità del sistema con livello di incapsulamento maggiore. Coesione: quanto le righe di codice (L0) che costituiscono una procedura (L1) sono necessarie per implementare le finalità della procedura stessa. Accoppiamento: misura delle connessioni fra due procedure (L1) Questo per la programmazione strutturata. E nel mondo OO?

41 + Metriche legate all incapsulamento nel mondo OO Coesione di classe: misura del grado di coesione fra le operazioni e gli attributi che costituiscono una classe e le finalità della classe stessa. Accoppiamento di classe: misura del grado di interdipendenza fra due classi A e B. Più in generale, dati due elementi software A e B (indipendentemente dal livello di incapsulamento), possiamo parlare di Conascenza quando: Una modifica ad A può richiedere la conseguente modifica di B Una modifica ad un terzo elemento può comportare la necessità di modificare A e B.

42 + Conascenza Due tipologie di conascenza sono evidenziabili: Conascenza statica: Di nome Di tipo Di convenzione: costanti, formati, et al. Di algoritmo Di posizione: posso invertire l ordine di A e B in compilazione? Conascenza dinamica: Temporale Di valore: invarianti da rispettare Di identità Di esecuzione: posso invertire l ordine di A e B in esecuzione?

43 + Conascenza e contronascenza La conascenza emerge quando due entità sw devono concordare su una proprietà, ad esempio il nome. Vi sono evidenti casi in cui invece due entità sw devono necessariamente divergere l uno dagli altri E.g.: dichiarazione di variabili già dichiarate nell ambito dello scope. Concetto di CONTRONASCENZA: necessità di diversità La conascenza è inevitabile nel software. E importante tuttavia ridurla quanto più entro i limiti dell incapsulamento Incapsulare, nascondere l implementazione ed esporre protocolli pubblici Ridurre la conascenza residua presente al di fuori dellincapsulamento

44 + I problemi derivanti dalla conascenza Lo sviluppatore 1 sviluppa una classe A per rappresentare i vettori di elementi che ha una caratteristica: i dati sono rappresentati in ordine inverse rispetto all ordine di inserimento Tale caratteristica non è mai stata documentata ma lo sviluppatore 1 ne fa uso in più punti del proprio sistema perché peculiare della implementazione di A Dopo anni si decide di rimpiazzare la classe A con una nuova classe B che, pur adottando lo stesso protocollo, non presenta la medesima caratteristica. Cosa succederà al software? Cosa fareste nei passi del programmatore 1? Qui non è un problema di codice, bensì di documentazione!!!

45 + Domande??? Grazie a tutti per l attenzione