© 2010 - CEFRIEL Java: il linguaggio Docente: Gabriele Lombardi

Presentazione sul tema: "© 2010 - CEFRIEL Java: il linguaggio Docente: Gabriele Lombardi"— Transcript della presentazione:

1 © 2010 - CEFRIEL Java: il linguaggio Docente: Gabriele Lombardi lombardi@dsi.unimi.it

2 © 2010 - CEFRIEL The present original document was produced by CEFRIEL and the Teacher for the benefit and internal use of this course, and nobody else may claim any right or paternity on it. No right to use the document for any purpose other than the Intended purpose and no right to distribute, disclose, release, furnish or disseminate it or a part of it in any way or form to anyone without the prior express written consent of CEFRIEL and the Teacher. © copyright Cefriel and the Teacher-Milan-Italy-23/06/2008. All rights reserved in accordance with rule of law and international agreements.

3 © 2010 - CEFRIEL Sommario SLIDECONTENUTO Sintassi base Poco più del procedurale Interfacce e classi Strumenti per lOOP Gestione delle eccezioni In sostituzione ai controlli di codici di errore Enums e annotations Da Tiger in avanti (jdk >= 1.5) Ereditarietà e implementazione Strumenti di riutilizzo del codice.. e di astrazione Altro Zucchero sintattico Generics Per ADT type-safe.. con type-erasure

4 © 2010 - CEFRIEL Intro: codice compilato VS interpretato Codice compilato: –veloce.. ma non portabile. Codice interpretato: –portabile.. ma lento. virtual machine (JVM): –codice compilato per una macchina inventata (bytecode); –interpretato da una virtual machine; –portabile (dove una JVM sia presente); –veloce (meno del codice compilato nativo); JIT (massimo della vita): –come precedente, ma … –… traduzione a run-time in codice nativo; –sparisce una vera e propria interpretazione; –viene eseguito codice nativo; –portabile (ove esista la JVM).. Ma veloce quanto (o più) del codice compilato per la macchina reale (perché più veloce?).

5 © 2010 - CEFRIEL Sintassi base declarations: –stessa sintassi del C: [= valore]; int pippo, pluto = 1;float paperino = 1E-6f; –non esistono i tipi senza segno (tipo unsigned long). statements & constructs: –stessa sintassi del C; –assegnamenti: = ; senza puntatori gli L-values di un assegnamento possono essere solo variabili, attributi o indicizzazione di array. –costrutti di selezione: if(){}if(){}else{}switch(){case 1: default:}. –costrutti di iterazione: while(){}do{}while();for(;;){} –aggiunti: for (int elemento: arrayDiInteri) { /* Uso elemento. */ } operators:gli stessi del C. tipi builtin:boolean, char, short, int, long, float, double modificatori:static, transient boxing/unboxing: –per ogni tipo builtin esiste una classe di boxing, istanziata in automatico alloccorrenza e spacchettata automaticamente se serve; –esempio:int java.lang.Integer

6 © 2010 - CEFRIEL Sintassi base dotted notation: –dato un oggetto, gli attributi (campi) ed i metodi vengono identificati come. ; –esempio:System.out.getClass().getName() reference-types VS value-types: –ogni oggetto è un tipo riferimento, quindi: assegnamento non clona ma copia il riferimento; side effects possibili se loggetto viene passato; –ogni tipo builtin è un valore, quindi: assegnamento per copia e side effects assenti. –Simulare i value-types: oggetti immutabili si evitano i side effects. semantica del passaggio dei parametri: –sempre per copia, ciò che viene copiato però può essere un riferimento, consentendo quindi la modifica delloggetto da parte del metodo. operatori particolari: –new:creazione di nuove istanze tramite costruttore: new String(123) la classe String contiene un metodo particolare capace di creare una stringa da un intero: –public String(int num) {…} –instanceof:RTTI, Run-Time Type Identification: if (myVar instanceof MyClass) controllo il tipo di myVar.

7 © 2010 - CEFRIEL Sintassi base dichiarazioni e gestione dello stack: –nella JVM ogni elemento occupa una locazione dello stack (con il proprio valore per i value-types, con il proprio riferimento (puntatore) per i reference-types. –un record di attivazione viene creato per ogni chiamata a metodo, eventualmente crescendo e decrescendo durante lesecuzione (dichiarazioni in mezzo al codice). –blocchi possono essere dichiarati per gestire la creazione e distruzione parti di record di attivazione in mezzo a un metodo: { // inizio del blocco // dichiarazioni nuove var. nel record di att. } // fine del blocco gestione della memoria: –richiesta solo lallocazione tramite costruttori e operatore new; –garbage collector di tipo mark-and-sweep per la deallocazione. strutture dati: –array di tipi builtin e di oggetti; un array è un oggetto array di array. –classi, enum, annotazioni.

8 © 2010 - CEFRIEL Classi descrivono delle tipologie di entità: –informazioni (attributi) che definiscono le caratteristiche di ogni istanza: esempio: class Colore { float red,green,blue; } –operazioni (metodi) per manipolarle accedendo agli attributi: esempio, mescolare un colore in un altro: class Colore {float red,green,blue; … void mescola(Colore c) { red = red*0.5+c.red*0.5; … } … } Colore c = new Colore(0,0,1); c.mescola(new Colore(1,0,0)); … nonché il loro concreto funzionamento: –contengono la desc. di come unentità si comporta (metodi astratti?); –cosa unentità è in grado di fare è meglio definirlo in uninterfaccia. possono essere utilizzate per realizzare: –value objects: mantenendo limmodificabilità degli attributi (immutables); –entities: evoluzione dello stato interno e mantenendo lidentità; –servizi: metodi che svolgono operazioni su richiesta, non su di sé; –factory: classi con lo scopo di creare istanze di altre classi (fabbriche). che ruolo fargli avere sta a noi (vedasi nel Domain Driven Design).

9 © 2010 - CEFRIEL Interfacce descrivono solamente il contratto di messaggistica: –gerarchia di tipi.. e non di classi/oggetti: utilizzata per il controllo di tipo a run-time; –chi le implementa dichiara cosa sa fare: dichiarazione dei metodi implementati da una determinata tipologia di classi; una classe può implementare più interfacce (simile allereditarietà multipla). separano behavior da implementation: –rendono inconsapevole il client: utilizza un oggetto di natura ignota conoscendone solamente le capacità o ruolo da esso coperto; –permettono di definire punti di astrazione: non dipendendo dalla classe di implementazione, si possono definire entità operanti su tipologie astratte di entità distinte per le loro capacità.

10 © 2010 - CEFRIEL Ereditarietà e implementazione Ereditarietà (tra classi): –solamente singola in Java (no ereditarietà multipla); –è uno strumento di riutilizzo diretto del codice; –specializzazione del funzionamento di una classe; –astrazione tramite classi astratte e polimorfismo; –definisce la relazione è un; –principio di sostituibilità di Liskov; –occhio allesempio classico rettangolo quadrato. Implementazione (di interfacce): –anche multipla e accoppiata allereditarietà; –è uno strumento di astrazione e validazione a compile-time (vedere prossimo punto); –definisce la relazione rispetta la specifica di un.

11 © 2010 - CEFRIEL Esempio fino a qui Quali i vantaggi di questarchitettura? Gli svantaggi? Astrazioni mancanti? Realizziamolo e giochiamoci!

12 © 2010 - CEFRIEL Enums Cosa sono? –entità esistenti in numero finito e noto a priori; –spesso definiscono opzioni di funzionamento; –possono rappresentare entità più complesse: unità di misura, costanti, comandi predefiniti, descrizioni di pacchetti, … Come funzionano: –sono dichiarati similarmente a classi; –prevedono una lista di chiamate ai propri costruttori; –vengono istanziati (teoricamente) prima dellesecuzione dellapplicazione (sperimentare); –NON possono essere istanziati esplicitamente; –permettono una sintassi ricca: specificazione di attributi e metodi; specializzazione per singolo valore.

13 © 2010 - CEFRIEL Annotations Cosa sono? –annotazioni allegate ad entità semantiche presenti nel codice (tipi, attributi, metodi, parametri,…); –possono trasportare informazione anche strutturata in maniera complessa (un albero per tipo di annotazione); –devono essere completamente definiti a compile-time; –possono essere osservati a run-time (reflection); Come funzionano? –non funzionano, semplicemente ci sono, e offrono accesso ai dati che contengono; –chi li usa si aspetta che vengano letti da qualche altra parte del SW, o da un framework utilizzato; –chi li legge offre funzionalità dichiarative a chi li utilizza; –consentono principalmente la metaprogrammazione; –si analizzi JUnit come esempio interessante.

14 © 2010 - CEFRIEL Gestione delle eccezioni Prima delle eccezioni: –[server]rilevato lerrore restituito codice descrittivo; –[client]controllato il codice presi dei provvedimenti; –un esempio: server: se BAD allora restituisci ERR; client: chiama server; controlla codice di errore; se ERR provvedi; chiama server; controlla codice di errore; se ERR provvedi; … Con le eccezioni: –[server]rilevato lerrore generata eccezione da gestire; –[client]svolge il proprio compito; cattura le eccezioni che gli interessano e provvede; lascia passare le altre così che qualcuno provveda. Risultato: codice più pulito e comprensibile.

15 © 2010 - CEFRIEL Generics Problema di partenza: –strutture dati internamente non tipizzate: utilizzo di Object come void* in C: –nessun check di tipo effettuabile a compile-time; ADT semplici non (banalmente) definibili: –Non basabili correttamente sulle API standard; –impossibile propagare informazione di tipo tra strutture dati, se non utilizzando la reflection; più lenta ed error-prone; –valutata a run-time; –richiede molti controlli per offrire robustezza; non validabile a run-time: –con controlli del tipo Mi dicono che classe vogliono, ma deve essere per forza figlia di X perché il tutto funzioni.; –esplosione di errori a run-time evitabili tramite check automatico. Soluzione: offrire uno strumento di manipolazione di tipi: –funzionante (solo) a compile time (non modifica le performance); –comprendente generalizzazione e vincoli verificabili dal compilatore durante la generazione del codice.

16 © 2010 - CEFRIEL Altro Package: –migliore granularità sulla visibilità; –organizzazione gerarchica degli aspetti/funzionalità; –ORDINE.. prima di tutto! Classi anonime (innestate, …): –permettono una immediata applicazione dellabstract method pattern (GoF, vedasi gestione eventi); –riducono il tempo di sviluppo; –MIGLIORANO la leggibilità del codice (se ben usate). Collections e iteratori: –concetti generali, entrati nella semantica.. e anche nella sintassi del linguaggio (non solo comodità). Varargs: –utili.. ma solo per semplificare la scrittura del codice.

17 © 2010 - CEFRIEL Esempio fino a qui Per ripassare tramite esempi in Code\01_Syntax: –EsempiSintassi\BaseSyntax.java sintassi di base del linguaggio. –EsempiSintassi\Exceptions.java –EsempiSintassi\Enums.java EsempiSintassi\Enums\*.java –EsempiSintassi\Generics.java –EsempiSintassi\Annotations.java sequenza consigliata per il ripasso. –EsempioTerminali esempio di cui si sono mostrati i diagrammi UML. –EsempioGruppi soluzione (parziale?) dellesercizio seguente: Costruire un package di manipolazioni di gruppi finiti (in senso algebrico) di value-objects; –occhio a cosa il gruppo deve contenere; –modellare prima dal punto di vista astratto; –occhio alle operazioni astratte; –usare lo zucchero sintattico visto in precedenza.