Componenti A.Natali Marzo 19991. 2 Oggetti u Un oggetto possiede stato, funzionamento e identita'. u Struttura e funzionamento di oggetti simili sono.

Presentazione sul tema: "Componenti A.Natali Marzo 19991. 2 Oggetti u Un oggetto possiede stato, funzionamento e identita'. u Struttura e funzionamento di oggetti simili sono."— Transcript della presentazione:

1 Componenti A.Natali Marzo 19991

2 2 Oggetti u Un oggetto possiede stato, funzionamento e identita'. u Struttura e funzionamento di oggetti simili sono definiti nella loro classe comune (di cui sono istanze). –I termini istance ed object sono intercambiabili

3 Componenti A.Natali Marzo 19993 Classi u Una classe descrive la struttura interna e il funzionamento di un oggetto. u Gli oggetti di una stessa classe hanno la stessa rappresentazione interna, le stesse operazioni e lo stesso funzionamento. name Attributes Operations

4 Componenti A.Natali Marzo 19994 Il ruolo del costrutto class u Permette protezione e information hiding u Usabile come modulo o come specifiche della struttura e del comportamento di oggetti u Consente di definire e realizzare tipi di dato (astratto)

5 Componenti A.Natali Marzo 19995 class: concetto o meccanismo? u Il costrutto class mescola vari piani: –specifica come si costruisce –specifica cosa si vede –specifica come e fatto –specifica come funziona

6 Componenti A.Natali Marzo 19996 Class: esempio u CAccount c1; c1 e una variabile di tipo CAccount, la classe che specifica –come si costruisce loggetto denotato da c1, –come e fatto loggetto denotato da c1 –quali sono le operazioni eseguibili sulloggetto denotato da c1

7 Componenti A.Natali Marzo 19997 Classi in UML CAccount # amount: Real + debit( v : Real ) + credit( v : Real ) + public - private # protected

8 Componenti A.Natali Marzo 19998 class CAccount public class CAccount { //Variabili istanza (variabili di stato) double amount = 0; //Costruttore CAccount( double v ){ amount = v; } //Metodi public void debit( double v ){ amount -= v; } public void credit( double v ){ amount += v; } }

9 Componenti A.Natali Marzo 19999 Oggetti e variabili CAccount c1; c1 e una variabile (di stile imperativo) che: u in C++: contiene la rappresentazione di una istanza della classe CAccount in Java: contiene un riferimento null ; Caccount c1=new Caccount(10);

10 Componenti A.Natali Marzo 199910 Classi e tipi u Molti linguaggi oo fanno coincidere il concetto di classe con quello di tipo. u Il concetto di classe non coincide pero con quello di tipo. u La classe e la realizzazione di un tipo di dato (astratto) u Il concetto di tipo e meglio catturato dal costrutto interface

11 Componenti A.Natali Marzo 199911 Classe e Interfaccia u Java introduce il costrutto interface che consente di definire una collezione di prototipi di operazioni ciascuna delle quali dovra' essere realizzata come metodo di una qualche classe. u Il costrutto interface complementa ed estende il costrutto class. u Il nome di una interfaccia puo' essere usato per denotare un tipo.

12 Componenti A.Natali Marzo 199912 ContoCorrente: interfaccia public interface IAccount{ public void debit( double v ); //prelievo public void credit( double v ); //deposito }

13 Componenti A.Natali Marzo 199913 La classe come realizzazione dellinterfaccia public class CAccount implements IAccount{... } IAccount c1 = new CAccount( 10 ); CAccount c2 = new CAccount( 20 ); c1 = c2;//SI c2 = c1;//NO ???? IAccount c3 = c2; //SI

14 Componenti A.Natali Marzo 199914 Contratti tra cliente e servitore u Linterfaccia esplicita una parte del contratto tra cliente e servitore –Le specifiche sintattiche non bastano u La classe garantisce la consistenza degli oggetti –Occorre esprimere e gestire casi di non conformita (eccezioni)

15 Componenti A.Natali Marzo 199915 Invarianti ed eccezioni u Il valore del conto corrente deve essere sempre superiore a un valore limite prefissato (per una certa categoria di clienti) u L'operazione debit non restituisce alcun valore in uscita, e quindi non e' in grado di segnalare una eventuale anomalia al cliente

16 Componenti A.Natali Marzo 199916 Una nuova specifica public interface IAccount{ public void debit( double v ) throws EOverDrawn; //prelievo con eccezione public void credit( double v ); //deposito } IAccount c1 = new CAccount( 10 ); try{ c1.debit( 500 ); }catch( Exception e ){ … }

17 Componenti A.Natali Marzo 199917 Una nuova realizzazione public class CAccount implements IAccount{ //VARIABILE DI CLASSE static double debitLimit = -10; //Variabili istanza (variabili di stato) double amount = 0; //Costruttore CAccount( double v ){ amount = v; } //Metodi public void credit( double v ){ amount += v; }

18 Componenti A.Natali Marzo 199918 Metodi con eccezione //Metodi public void debit( double v ) throws EOverDrawn;{ double t = amount - v; if( v > debitLimit ) amount = t; else throw new EOverDrawn(); }//debit }//

19 Componenti A.Natali Marzo 199919 Consistenza ed asserzioni Invariant == (amount > debLimit) public void debit( double v ) throws EOverDrawn;{ require: true; double t = amount - v; if( v > debitLimit ) amount = t; else throw new EOverDrawn(); ensure: (amount==oldAmount-v) && invariant }//debit

20 Componenti A.Natali Marzo 199920 La classe nella progettazione u Apre la via alla specifica incrementale del software secondo i principi-base del modello ad oggetti (un modello non ancora completamente specificato)

21 Componenti A.Natali Marzo 199921 Modello ad oggetti u I concetti su cui si basa: –classi –oggetti –e sulle loro relazioni sono usabili in modo seamless come building blocks in tutte le fasi dello sviluppo del software: u E orientato alla progettazione per il cambiamento

22 Componenti A.Natali Marzo 199922 La progettazione per il cambiamento u Supporta l'intera sequenza che va dai requisiti (o dalla loro modifica) al sistema funzionate u Supporta lo sviluppo iterativo di un sistema lungo il tutto il suo tempo di vita u Concepisce ciascuna iterazione come una modifica a un sistema esistente

23 Componenti A.Natali Marzo 199923 Una nuova specifica u Il conto corrente deve contenere una lista dei movimenti effettuati u Invariante: –La lista dei movimenti deve corrispondere alla sequenza di richieste

24 Componenti A.Natali Marzo 199924 Ereditarieta u Nasce come una relazione tra classi in cui una classe condivide la struttura e/o il funzionamento definito in un'altra classe (ereditarieta' singola) o in varie altre classi (ereditarieta' multipla). u Scaturisce dall'esigenza di introdurre un meccanismo per condividere (parti di) una descrizione, cioe' per riusare codice gia' funzionante.

25 Componenti A.Natali Marzo 199925 Specifica incrementale public interface IACCOUNT extends IAccount{ public String toString(); //rapprresent. esterna public String log(); //lista movimenti }//IACCOUNT

26 Componenti A.Natali Marzo 199926 Ereditarieta: concetto o meccanismo? u L'interpretazione di una classe come un tipo di dato (astratto) induce a vedere lereditarieta' come un meccanismo per definire sottotipi. Si parla in questo caso di ereditarieta' strict. u L'ereditarieta' tra classi intese come tipi puo' essere interpretata come un meccanismo per introdurre polimorfismo

27 Componenti A.Natali Marzo 199927 Polimorfismo u In linguaggi polimorfici un valore o una variabile puo' denotare istanze di molti diversi tipi ( classi ) ammesso che questi siano collegati tra loro da relazioni tipo-sottotipo ( classe-sottoclasse ). dataType min(dataType v1, dataType v2)

28 Componenti A.Natali Marzo 199928 Vincoli imposti dalle relazioni sui tipi u Un sottotipo T1 di un tipo T introduce vincoli addizionali alla specifica di T, cui corrisponde un sottoinsieme piu' limitato di oggetti rispetto all'insieme di oggetti definito da T. –Una variabile di tipo T puo' denotare un oggetto di tipo T1 ma non viceversa –Infatti e' vero che ogni oggetto di tipo T1 e' anche di tipo T, ma non e' vero il contrario

29 Componenti A.Natali Marzo 199929 La regola di conformita u Ogni oggetto di tipo T1, sottotipo di T, puo essere usato in tutti i contesti in cui e' ammissibile un oggetto del tipo T.

30 Componenti A.Natali Marzo 199930 Ereditarieta e subtyping u La specifica di un sottotipo deve continuare a soddisfare ai vincoli del tipo-genitore. –come garantire la regola di conformita' ? –cosa significa raffinare il contratto rappresentato dall'interfaccia e dal funzionamento di una classe?

31 Componenti A.Natali Marzo 199931 Realizzazione incrementale public class CACCOUNT extends CAccount implements IACCOUNT{ // eredita struttura e operazioni di CAccount // accede alle variabili private di CAccount // specializza le vecchie operazioni // realizza le nuove operazioni di IACCOUNT

32 Componenti A.Natali Marzo 199932 Realizzazione incrementale // specializza le vecchie operazioni public void credit( double v ){ logObj.add(credit + v ); amount += v; //MEGLIO DI NO!! }//credit L'ereditarieta' puo' compromettere il principio dell'incapsulamento dell'informazione se una classe derivata ha accesso ai dati di una classe genitore.

33 Componenti A.Natali Marzo 199933 Qualificatori di accesso u public u private u protected nessuno: in Java vi e una visibilita a livello di package

34 Componenti A.Natali Marzo 199934 Realizzazione incrementale // specializza le vecchie operazioni public void credit( double v ){ logObj.add(credit + v ); super.credit( v ); }//credit Si riusa loperazione precedente

35 Componenti A.Natali Marzo 199935 Realizzazione incrementale // realizza le nuove operazioni di IACCOUNT Vector logObj = new Vector(10,5); public String toString(){ return + amount; } public String log(){ return logObj; }//log }//CACCOUNT

36 Componenti A.Natali Marzo 199936 Una operazione polimorfica void credit100( CAccount a1 ){ a1.credit( 100 ); }//credit100; IAccount c1 = new CAccount( 10 ); IACCOUNT c2 = new CACCOUNT( 20 ); credit100( c1 ); credit100( c2 ); System.out.println( c2.log() );

37 Componenti A.Natali Marzo 199937 Java vs. C++ u In C++ loperazione precedente non e polimorfica: –il trasferimento degli argomenti implica la copia degli oggetti –il meccanismo di binding e di tipo eager, mentre il polimorfismo richiede un meccanismo di late binding

38 Componenti A.Natali Marzo 199938 Progetto orientato al cambiamento u Operazioni aperte u Operazioni primitive (dipendenti dalla rappresentazione) e non u Classi astratte

39 Componenti A.Natali Marzo 199939 Operazioni aperte A + m1( v : Real ) + m2( v : Real ) B m1 chiama m2 il funzionamento di m1 dipende dalloggetto che la sta eseguendo

40 Componenti A.Natali Marzo 199940 Operazioni non primitive list insOrd( list l1, listData x){ if ( l1.isEmpty() ) return nl.addFirst( x ); else if ( x.less( l1.head() ) ) return l1.addFirst(x); else return insOrd( l1.tail(),x ).addFirst(x); }//insOrd

41 Componenti A.Natali Marzo 199941 Classe astratta u Consente di fattorizzare uninterfaccia comune a un insieme di sottotipi (sottoclassi) u Definisce il codice delle operazioni non primitive, lasciando alle sottoclassi la specifica del codice delle primitive (metodi abstract) u Può definire variabili