Ereditarietà e incapsulamento

Trascrizione diapositive

1. Ereditarietà e incapsulamento

• Complessità: MEDIA.

2. I paradigmi della programmazione ad oggetti

• Se il lettore ha appreso tutti i concetti espressi nelle precedenti unità, sarà in grado di conoscere le basi della programmazione Java. Ciò nonostante è opportuno imparare a scrivere il codice in modo corretto, poiché occorre realizzare applicazioni che siano robuste e sicure.
• Ciò che caratterizza un linguaggio orientato agli oggetti è il supporto che esso offre ai cosiddetti paradigmi della programmazione ad oggetti, essi sono:
  
  - Incapsulamento
  - Ereditarietà
  - Polimorfismo


• È anche necessario comprendere i paradigmi della programmazione procedurale che in Java sono spesso considerati secondari, ma che invece restano molto utili, essi sono:
  
  - Astrazione
  - Riuso
  

3. Astrazione

• L’astrazione è un paradigma della programmazione procedurale che potremmo definire come l’arte di sapersi concentrare solo sui dettagli veramente essenziali per far funzionare correttamente un programma.
• L’astrazione si divide in tre livelli:
  
  - Astrazione funzionale
  - Astrazione dei dati
  - Astrazione di sistema


• Adoperiamo l’astrazione funzionale ogni volta che implementiamo un metodo. Un metodo che come abbiamo già affermato è sinonimo di azione, deve essere implementato in modo efficace. Quando l’azione verrà invocata deve, quindi, restituire in ogni caso il risultato voluto.
• Adoperiamo l’astrazione dei dati ogni volta che definiamo una classe, raccogliendo in essa solo le caratteristiche (attributi) e le funzionalità (metodi) essenziali per gli oggetti.
• Adoperiamo l’astrazione di sistema ogni volta che definiamo tutte le classi essenziali che devono soddisfare gli scopi dell’applicazione stessa.
  

4. Riuso

• Con il termine riuso di codice si intende la pratica, estremamente comune nella programmazione, di richiamare o invocare parti di codice precedentemente già scritte ogni qualvolta risulti necessario senza, in questo modo, doverle riscrivere daccapo.
• Il riuso è quindi da considerarsi come una conseguenza dell’astrazione e degli altri paradigmi della programmazione ad oggetti, quindi dell’incapsulamento, dell’ereditarietà e del polimorfismo.

5. Incapsulamento

• L’incapsulamento permette di controllare l’accesso alle variabili, mediante l’uso di metodi che possono prevenire la non correttezza dei dati.

A tale scopo verrà trattato in modo approfondito il modificatore di tipo «private».

• La tecnica dell’incapsulamento ci aiuterà ad effettuare operazioni di modifica e manutenzione del codice, perché i cambiamenti sono localizzati e non globali, e quindi si riduce notevolmente il rischio di introdurre errori e di conseguenza il tempo necessario per eseguire le operazioni di test e debug.

6. Incapsulamento

• Supponiamo di voler scrivere un’applicazione che utilizza il seguente modello per definire un oggetto di tipo «Data»:


• class Data {
  
  public int giorno;
  public int mese;
  public int anno;
  }


• Supponiamo ancora di voler creare un oggetto di tipo «Data», valorizzando al suo interno le variabili definite nella classe, dovremo scrivere in questo modo:

public class Programma {
public static void main(String args[]) {
Data unaData = new Data();
unaData.giorno = 12;
unaData.mese = 10;
unaData.anno = 1990;
}
}

7. Incapsulamento

• Ipotizziamo di implementare una funzione che permette di far inizializzare le variabili ad un semplice utente tramite interfaccia grafica. Le variabili adesso verranno inizializzate nel seguente modo:
  
  - Valore «40» per il giorno.
  - Valore «80» per il mese.
  - Valore «2000» per l’anno.


• In questo caso è chiaro a tutti che si tratta di una data non valida, ma il programma (per come è stato concepito) non restituirà alcun messaggio di errore!
• È evidente che manca un controllo per la validazione dei valori che può assumere una variabile d’istanza.

8. Incapsulamento

• A seguito di quanto appena affermato nella precedente slide, la classe «Data» dovrà essere riscritta nel seguente modo:

[Download]

(Prima parte del codice)

class Data {

9. Incapsulamento

• A seguito di quanto appena affermato nella precedente slide, la classe «Data» dovrà essere riscritta nel seguente modo:



[Download]

(Seconda parte del codice)

public void setMese(int m) {
if (m > 0 && m<=12) {
mese=m;
} else {
System.out.println(“Mese non valido.”);
}
}
public int getMese() {
return mese;
}
public void setAnno(int a) {
anno=a;
}
public int getAnno() {
return anno;
}
}

10. Incapsulamento

• L’incapsulamento come abbiamo forse già intuito dalla stesura del nuovo codice, è da considerarsi un passo importante per rendere più sicuro e robusto il nostro programma. La procedura che abbiamo seguito è semplice:
  
  - Abbiamo dichiarato tutte le variabili di tipo «private».
  - Abbiamo implementato dei metodi pubblici per accedere alle variabili «private», sia in scrittura «set» e sia in lettura «get».


• Questo modo di lavorare ci permette di usufruire dei seguenti vantaggi:
  
  - Con l’operatore d’appartenenza «.» non possiamo più accedere direttamente al dato perché è dichiarato di tipo «private», ciò è un importante beneficio. L’utente che vuole modificare le variabili d’istanza deve forzatamente invocare un metodo (che volendo può impedire tale modifica). Quindi ogni oggetto d’ora in avanti conterrà valori corretti, di conseguenza l’applicazione funzionerà a dovere!
  - Il codice è molto più facile da manutenere e si adatta ai cambiamenti.

11. Incapsulamento

• Di seguito vediamo come dovrà essere riscritto il metodo «main()», conseguentemente alle nuove modifiche effettuate:

[Download]

public class Programma { }

• L’esecuzione del codice non restituirà alcun messaggio di errore, le variabili d’istanza saranno inizializzate in modo corretto.
• Nel caso avessimo provato ad inizializzare la variabile «giorno» al valore «32», in fase di esecuzione ci sarebbe stato restituito il messaggio «Giorno non valido.».

12. Incapsulamento

• Al lettore dovrebbe adesso risultare chiara l’utilità dei metodi «set» (mutator methods) implementati, potrebbe però avere qualche riserva sui metodi «get» (accessor methods).
• Supponiamo di voler stampare a video la variabile privata «giorno», scrivendo in questo modo (nel metodo «main()») ci verrà restituito un errore in compilazione:

System.out.println(unaData.giorno);

• Questo perché la variabile «giorno» è dichiarata di tipo «private», a questo punto è necessario invocare il metodo «getGiorno()» per restituire la variabile desiderata. L’unica soluzione è quindi:

System.out.println(unaData.getGiorno());

13. Incapsulamento

• Ricordiamo che anche i metodi «get» (accessor methods) potrebbero effettuare controlli, proprio come i metodi «set» (mutator methods).
• È facile immaginare, ad esempio, una classe come questa:

class ContoAziendale {
private String contoAziendale = "500 Euro";
private String codiceSegreto = "NostroConto";
private String codiceUtente;
public void setCodiceUtente(String cod) {
codiceUtente = cod;
}
public String getCodiceUtente() {
return codiceUtente;
}
public String getContoAziendale() {
if(codiceUtente == codiceSegreto) {
return contoAziendale;
} else {
return "Codice errato!";
}
}
}

14. Incapsulamento

• Ma è anche possibile immaginare una classe che utilizza metodi che fanno uso del modificatore «private», ecco come si potrebbe evolvere l’esempio elaborato precedentemente:

class ContoAziendale { }

• Naturalmente dal metodo «main()» possiamo invocare esclusivamente il metodo «getContoAziendale()», passando come parametro il nostro codice segreto che deve essere di tipo «String».

15. Incapsulamento

• Da notare il fatto che a partire da due oggetti istanziati dalla stessa classe possono nell’ambito della classe, accedere direttamente ai rispettivi membri privati come se fossero pubblici. Come ci viene mostrato in questo esempio:

[Download]

class Dipendente { }

16. Incapsulamento

• Qui di seguito un esempio di metodo «main()» che riguarda la classe «Dipendente» (vista in precedenza). Il risultato restituito dal programma sarà «1», esattamente la differenza tra il punteggio ottenuto dal dipendente «Fabrizio» nei confronti di «Fabio».



[Download]

public class Programma {
public static void main(String args[]) {
Dipendente fabrizio = new Dipendente();
Dipendente fabio = new Dipendente();
fabrizio.setNome("Fabrizio");
fabio.setNome("Fabio");
fabrizio.setPunteggio(7);
fabio.setPunteggio(6);
System.out.println(fabrizio. getDifferenzaPunteggio(fabio));
}
}

17. Il reference this

• Analizzando ancora una volta l’esempio della classe «Dipendente», ci dobbiamo rendere conto che per ogni variabile d’istanza può essere specificato esplicitamente il nome dell’oggetto di appartenenza (reference). Nello specifico basta osservare la variabile «altro.punteggio» per comprendere che appartiene all’oggetto passato sotto forma di parametro.
• Notiamo sempre dal precedente esempio che per tutte le altre variabili non è stata specificata esplicitamente la propria istanza di appartenenza, in realtà si tratta di un’iniziativa del compilatore Java. Se il programmatore non referenzia espressamente una certa variabile d’istanza, al momento della compilazione il codice sarà modificato dal compilatore stesso, che aggiungerà un reference all’oggetto corrente, per oggetto corrente si intende l’oggetto che invoca il metodo.
• Java introduce una parola chiave che per definizione coincide ad un reference all’oggetto corrente: «this». La parola chiave «this» viene quindi implicitamente aggiunta nel bytecode compilato, per referenziare ogni variabile d’istanza non esplicitamente referenziata.

18. Il reference this

• Per rendere ancora più chiara l’utilità del reference «this» vediamo (con le conoscenze fino ad ora acquisite) come la classe «Dipendente» viene riscritta dal compilatore javac:

class Dipendente { }

19. Due stili di programmazione a confronto

Senza reference this:

class Dipendente {
... ...
}

Con reference this:

class Dipendente {
... ...
}

20. Quando utilizzare l’incapsulamento?

• Non ci sono casi in cui è opportuno o meno utilizzare l’incapsulamento. Una qualsiasi classe di un qualsiasi programma dovrebbe essere sviluppata utilizzando l’incapsulamento.
• Anche se all’inizio di un progetto può sembrarci che su determinate classi usufruire dell’incapsulamento sia superfluo, l’esperienza insegna che è preferibile applicarlo in ogni situazione.

21. Ereditarietà

• L'ereditarietà è uno dei concetti fondamentali del paradigma della programmazione ad oggetti.
  Essa consiste in un legame che il linguaggio di programmazione, o il programmatore stesso, stabilisce tra due classi.
• Se la classe «B» eredita dalla classe «A», si dice che «B» è una classe derivata (o sottoclasse) di «A» e che «A» è una classe principale (o superclasse) di «B».

22. La parola chiave extends

• Consideriamo la seguente classe principale:

class Persona { }

• Adesso consideriamo quest’altra classe derivata dalla principale (senza l’utilizzo della tecnica di ereditarietà):

class Studente { }

• Notiamo che la classe «Persona» e la classe «Studente» rappresentano due modelli in relazione tra loro e quindi dichiarano campi in comune. L’ereditarietà permette di mettere in relazione due classi in maniera tale da implementare nella sottoclasse: le variabili pubbliche ed i metodi pubblici presenti nella superclasse. Nel nostro caso possiamo fare in modo che la classe «Studente» erediti tutte le variabili pubbliche dalla classe «Persona» senza dichiarale esplicitamente…

23. La parola chiave extends

• Alla luce di quanto affermato, la classe «Studente» deve essere riscritta in questo modo:

class Studente extends Persona { }

• Dal codice mostrato si evince che nella classe «Studente» sono dichiarate implicitamente le variabili pubbliche presenti nella classe «Persona».
• È doveroso precisare che anche i metodi pubblici dichiarati nella superclasse saranno ereditati dalla sottoclasse; nel caso del nostro esempio, tuttavia, non è stato specificato alcun metodo pubblico nella classe «Persona».
• È evidente il risparmio di codice come anche il risparmio di tempo per quanto riguarda la definizione del modello derivato, il vantaggio è anche quello di una minor probabilità di commettere eventuali errori.

24. Ereditarietà multipla

• In Java non esiste la cosiddetta ereditarietà multipla.
• L’ereditarietà multipla permette ad una classe di ereditare da più classi contemporaneamente. In pratica non è possibile scrivere:

class Idrovolante extends Aereo, Nave {

...

}

• Anche se a livello concettuale l’ereditarietà multipla esiste, non possiamo implementarla in un programma, perché potrebbero nascere delle complicazioni tali che il programmatore potrebbe non riuscire a venirne a capo.

25. La classe Object

• Bisogna notare che il compilatore (come oramai sappiamo bene) aggiunge automaticamente del codice.
• È bene sapere, quindi, che ogni classe principale è sottoclasse della classe «Object». Quando scriviamo:

class Persona {

...

}

Il compilatore aggiungerà automaticamente:

class Persona extends Object {

...

}

• Quindi possiamo affermare che ogni classe è direttamente o indirettamente sottoclasse della classe «Object».

26. Complicazione dell’ereditarietà multipla