Principi OOP A.Natali Aprile 19991 Principi di oop Dai costrutti alle metodologie.

Principi OOP A.Natali Aprile 1999

Principi di oop

Dai costrutti alle metodologie

Costrutti Java Dati primitivi e strutture di controllo:

– identiche a quelle del linguaggio C Interfacce

– come specifiche contrattuali Classi

– come moduli /come specifiche della struttura e del comportamento di oggetti

Packages– come contenitori

Architettura di riferimento

Sistemi software intesi come collezioni di componenti (oggetti) – in uno stesso spazio di indirizzamento o

distribuiti in rete– associati a domini di protezione– supportati da sistemi operativi multitasking e a

finestre

API Packages

Elenco JDK 1.2.1

Java packages

java.lang Package that contains essential Java classes, including numerics, strings, objects, compiler,

runtime, security, and threads. This is the only package that is automatically imported into every Java program.

java.io Package that provides classes to manage input and output streams to read data from and write data to files, strings, and other sources.

Java packagesjava.util Package that contains miscellaneous utility

classes, including generic data structures, bit sets, time, date, string manipulation, random number generation, system properties, notification, and enumeration of data structures.

java.net Package that provides classes for network support, including URLs, TCP sockets, UDP sockets, IP addresses, and a binary-to-text converter.

Java packagesjava.awt Package that provides an integrated

set of classes to manage user interface components such as windows, dialog boxes, buttons, checkboxes, lists, menus, scrollbars, and text fields. (AWT = Abstract Window Toolkit)

java.awt.image Package that provides classes for managing image data, including color models, cropping, color filtering, setting pixel values, and grabbing snapshots.

Java packages

java.applet Package that enables the creation of appletsthrough the Applet class. It also provides several interfaces that connect an applet to its document and to resources for playing audio.

Il ruolo del costrutto class

Permette protezione e information hiding Usabile come modulo o come specifiche della

struttura e del comportamento di oggetti Consente di definire e realizzare tipi di dato

(astratto)

class: concetto o meccanismo?

Il costrutto class mescola vari piani:

– specifica come si costruisce– specifica cosa si vede– specifica come e’ fatto– specifica come funziona

Class: esempio

CAccount c1;

c1 e’ una variabile di tipo CAccount, la classe che specifica – come si costruisce l’oggetto denotato da c1, – come e’ fatto l’oggetto denotato da c1 – quali sono le operazioni eseguibili sull’oggetto

denotato da c1

Specifica UML

CAccount

# amount: Real

+ debit( v : Real )+ credit( v : Real )

+ public- private# protected

class CAccount

public class CAccount {//Variabili istanza (variabili di stato)double amount = 0;

//CostruttoreCAccount( double v ){ amount = v; }

//Metodipublic void debit( double v ){ amount -= v; }public void credit( double v ){ amount += v; }}

Oggetti e variabili

CAccount c1;

c1 e’ una variabile (di stile imperativo) che: in C++: contiene la rappresentazione di

una istanza della classe CAccount in Java: contiene un riferimento null;

Caccount c1=new Caccount(10);

Classi e tipi

Molti linguaggi oo fanno coincidere il concetto di classe con quello di tipo.

Il concetto di classe non coincide pero’ con quello di tipo.

La classe e’ la realizzazione di un tipo di dato (astratto)

Il concetto di tipo e’ meglio catturato dal costrutto interface

Classe e Interfaccia

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.

Il costrutto interface complementa ed estende il costrutto class.

Il nome di una interfaccia puo' essere usato per denotare un tipo.

ContoCorrente: interfaccia

public interface IAccount{

public void debit( double v ); //prelievopublic void credit( double v ); //depositopublic String toString(); //lettura

La classe come realizzazione dell’interfaccia

public class CAccount implements IAccount{...}

IAccount c1 = new CAccount( 10 );CAccount c2 = new CAccount( 20 );

c1 = c2; //SIc2 = c1; //NO

IAccount c3 = c2; //SI

Contratti tra cliente e servitore

L’interfaccia esplicita una parte del contratto tra cliente e servitore– Le specifiche sintattiche non bastano

La classe garantisce la consistenza degli oggetti– Occorre esprimere e gestire casi di non

conformita’ (eccezioni)

Invarianti ed eccezioni

Il valore del conto corrente deve essere sempre superiore a un valore limite prefissato

L'operazione debit non restituisce alcun valore in uscita, e quindi non e' in grado di segnalare una eventuale anomalia al cliente

Eccezioni L'insorgere durante una computazione di eventi anomali,

quali violazioni di asserzioni, errori, esaurimento della memoria, etc. induce normalmente un aborto del programma.

Il concetto di eccezione e i correlati meccanismi di exception handling consentono di continuare l'esecuzione e di gestire l'evento anomalo.

Il modello Resumption

Il controllo delle eccezioni segue un modello simile alla ricezione di un interrupt. – Il flusso normale di controllo e' sospeso per

eseguire l'intervento di gestione dell'evento e poi riprende il normale flusso di controllo e' definitivamente interrotto e trasferito a un exception handler

Il modello Termination

Al manifestarsi di una eccezione, il normale flusso di controllo e' definitivamente interrotto e trasferito a un exception handler

Gestione delle eccezioni in Java

Java (come C++) supporta una semantica di terminazione

il sistema effettua automaticamente lo stack unwinding– dealloca i record di attivazione delle operazioni

attive fino al cliente (in C++ chiama i distruttori degli oggetti in vita sullo stack)

Eccezioni: specifica e generazione

public void op( ... )

throws ExceptionXX{

… throw new ExceptionXX();

Eccezioni come oggetti

le eccezioni sono intese come oggetti, istanza di una opportuna gerarchia di exception classes.

La gestione della eccezione segue la metafora lancia un oggetto, e cattura un tipo

Eccezioni: gestione

Un cliente puo' invocare una operazione prevedendo che il servitore possa rispondere sollevando una eccezione:

try { <action call>; }catch( <oggetto> ) {

<exception handling>}

Eccezioni: metodologia

Non bisogna usare le eccezioni come un meccanismo di controllo convenzionale.

Seguendo la metafora "lancia un oggetto, e cattura un tipo" conviene che gli argomenti di catch appartengano a classi di eccezioni appositamente definite.

L’eccezione EOverDrawn

public class EOverDrawn extends Exception{};

Una nuova specifica

public interface IAccount{public void debit( double v )

throws EOverDrawn; //prelievo con eccezionepublic void credit( double v ); //depositopublic String toString(); //lettura}IAccount c1 = new CAccount( 10 );

try{c1.debit( 500 );

}catch( Exception e ){ … }

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; }

Variabili di classe

Sono qualificate static Sono condivise tra tutte le istanze di una

classe Possono essere inizializzate a compile time Sono accessibili dalle normali operazioni

Prelievo con eccezione

//Metodipublic void debit( double v )

throws EOverDrawn;{ double t = amount - v;

if( v > debitLimit ) amount = t; else throw new EOverDrawn();

}//debit

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

Rappresentazione esterna

//Metodi

public String toString(){ return ("conto="+ amount + " EURO\n");

}//toString

}//CAccount

Un main program

//file testCAccount.javapublic class testCAccount{static void prelievo( IAccount c1 ){

try{ c1.debit( 500 );}catch( Exception e ){ System.exit(); }

}// prelievopublic static void main( String[] args ){ IAccount c1 = new CAccount( 10 );CAccount c2 = new CAccount( 20 );IAccount c3 = c2;

c1.credit( 20 ); prelievo(c1, 300);}//main}// testCAccount

Metodi static

Possono essere invocati senza istanziare alcun oggetto– le class sono usabili come singoli oggetti

(moduli)

Non possono accedere a variabili istanza Possono invocare solo altri metodi static

Compilazione ed esecuzione

javac EOverDrawn.java javac IAccount.java javac CAccount.javajavac testAccount.java

java testAccount

Principi supportati

Protezione dell’informazione e minimi privilegi di accesso

Separazione tra specifica e implementazione Barriere di astrazione e indipendenza dalla

rappresentazione Modello client-server e contratti d’uso Componenti come enti che preservano invarianti

La progettazione per il cambiamento

Il ruolo dell’ereditarieta’

Progettazione incrementale

L’ereditarieta’ tra classi apre la via alla specifica incrementale del software

il modello ad oggetti (anche se non completamente specificato) e’ orientato alla progettazione per il cambiamento– i concetti su cui si basa sono usabili in modo seamless

come building blocks in tutte le fasi dello sviluppo del software

Ereditarieta’

– 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).

– Scaturisce dall'esigenza di introdurre un meccanismo per condividere (parti di) una descrizione, cioe' per riusare codice gia' funzionante.

La progettazione per il cambiamento

Supporta l'intera sequenza che va dai requisiti (o dalla loro modifica) al sistema funzionate

Supporta lo sviluppo iterativo di un sistema lungo il tutto il suo tempo di vita

Concepisce ciascuna iterazione come una modifica a un sistema esistente

Ereditarieta’ in Java

Tra interfacce: come meccanismo incrementale di specifica di contratti

Tra classi: come meccanismo di riuso di (specifiche di) implementazioni

Una nuova specifica

Il conto corrente deve contenere una lista dei movimenti effettuati

Invariante:– La lista dei movimenti deve corrispondere alla

sequenza di richieste

Specifica incrementale (IConto)

public interface IConto extends IAccount{

public String log(); //lista movimenti

}//IConto

Ereditarieta’: concetto o meccanismo?

Ereditarieta’ is-a– Se B eredita da A, ogni istanza di B ha le stesse

proprieta’ delle istanze di A

Ereditarieta’ is-like– Se B eredita da A, ogni istanza di B ha in se’ la

struttura e il codice delle istanze di A

Ereditarieta’ tra classi

Una classe derivata eredita – tutti i campi dati (tranne private)

– i metodi public e protected

Una classe derivata non eredita– costruttori

– (in C++) distruttore, costruttore di copia, assegnamento

Ereditarieta’: concetto o meccanismo?

L'interpretazione di una classe come un tipo di dato (astratto) induce a vedere l’ereditarieta' come un meccanismo per definire sottotipi. Si parla in questo caso di ereditarieta' strict.

L'ereditarieta' tra classi intese come tipi puo' essere interpretata come un meccanismo per introdurre polimorfismo

In Java “ogni cosa e’ un object”class java.lang.Object

class java.lang.reflect.Array

class java.lang.ClassLoader

class java.awt.Color (implements java.io.Serializable)

class java.awt.Component

(implements java.awt.image.ImageObserver,

java.awt.MenuContainer, java.io.Serializable)

Polimorfismo

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)

Vincoli imposti dalle relazioni sui tipi

Un sottotipo T1 di un tipo T introduce vincoli addizionali alla specifica di T – A T1 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

La regola di conformita’

Ogni oggetto di tipo T1, sottotipo di T, puo’ essere usato in tutti i contesti in cui e' ammissibile un oggetto del tipo T.

Ereditarieta’ e subtyping

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?

IComplex

IReal X

IParolaP

parolaLimitata

parolaNonLimitata

IParola p1 = new A(..);p1.charAt( 3 );

P p2=new B(…);p2.charAt(…);

P p2=new P(…);p2.charAt(…);

IParolaP

parolaLimitata

parolaNonLimitata

public char head(){return charAt( 1 );

IParola p1 = new A(..);char x = p1.head( );

Realizzazione incrementale (CConto)

public class CConto extends CAccount implements IConto{

// eredita struttura e operazioni di CAccount// accede alle variabili di CAccount

// specializza le vecchie operazioni // realizza le nuove operazioni di IConto

Realizzazione incrementale// specializza le vecchie operazioni

public void credit( double v ){ logObj.addElement(“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

Qualificatori di accesso

public private protected

nessuno: per Java vi e’ una visibilita’ a

livello di package

Realizzazione incrementale

// specializza le vecchie operazioni

public void credit( double v ){ logObj.add(“credit “+ v );

super.credit( v );}//credit

Si riusa l’operazione precedente

public void debit( double v ) throws EOverDrawn{//rispeciifca completa per inserire anche il log delle eccezionidouble newamount = amount - v; if ( newamount >= getLimit() ) { //per maggior riuso

amount = newamount;logObj.addElement( new Movimento("prelievo: "+

getTime(), v) ); }else {

logObj.addElement( new Movimento("prelievo rifiutato: "+getTime(), v) );

throw new EOverDrawn();}

}//debit

// realizza le nuove operazioni di IConto

Vector logObj = new Vector(10,5);

public String log(){ String s =“”; for(int i = 0; i < logObj.size(); i++ )

s=s+logObj.elementAt(i).toString()+"\n";

}//log

}//CConto

Una operazione polimorfica

static void prelievo( IAccount c1, double v){try{ c1.debit( v );}catch( Exception e ){

System.out.println("ERROR: " + e );System.exit(-1);

} }//prelievo

E’ possibile trasferire come valori a c1 oggetti di classeCAccount o di una qualsiasi sua sottoclasse (CConto)

Java vs. C++

static void prelievo( CAccount c1,...)

In C++ questa operazione 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

Il problema della costruzione

La costruzione di un oggetto procede in due fasi:– costruzione della parte ereditata dalla classe

base (e ricorsivamente dalle superclassi)– costruzione della parte specifica

Il problema della costruzione

La costruzione della parte ereditata puo’ essere indotta– esplicitamente con super( … )– implicitamente (il sistema chiama il costruttore

a zero argomenti della classe base) Java NON disattiva (come fa il C++) il

meccanismo del late binding entro i costruttori

Tecnica errata di costruzione

public CConto( double v ){

super( v );System.out.println("costruito il CConto: " + this );

Produce un errore a tempo di esecuzione– il costruttore della classe base invoca la

versione specializzata di credit che accede a una variabile logObj non ancora esistente

Costruzione

public CConto( double v ){

amount = 0;

credit( v ); //late binding

System.out.println("costruito il CConto: " + this );

Un nuovo test

public static void main( String[] args ){

CConto c0 = new CConto( 20 );

IConto c1 = c0;

c1.credit( 20 );

prelievo( c1, 10 );

prelievo( c1, 3000 );

System.out.println("movimenti del conto c1: \n" + c1.log() );

}//main

Risultati

costruttore di default di CAccount: conto=0.0 EUROcostruito il CConto: conto=20.0 EURO

ERROR: account.EOverDrawnmovimenti del conto c1:deposito: 132/19:1:12 di 20.0 EUROdeposito: 132/19:1:12 di 20.0 EUROprelievo: 132/19:1:12 di 10.0 EUROprelievo rifiutato: 132/19:1:12 di 3000.0 EURO

Tecniche di progetto oo

Dai meccanismi ai sistemi

Tecniche elementari di progetto

Operazioni “aperte” Operazioni primitive (dipendenti dalla

rappresentazione) e non Classi astratte Wrapping

Operazioni “aperte”

+ m1( v : Real )+ m2( v : Real )

+ m2( v : Real )

m1 chiama m2il funzionamento di m1 dipende dall’oggetto che la sta eseguendo

Barriera di astrazione

null: -> listcons : element, list -> list

a, [ 1, 2 ] -> [a,1,2]head: list -> element

head([a,1,2]) -> atail: list -> list

tail ([a,1,2]) -> [1,2]isEmpty list -> boolean

Liste: primitive

Delete: element el, list l1 -> list

if( isEmpty(l1) ) return l1;if( equal( head(l1), el ) return

delete( el, tail(l1) );return cons(head(l1),

delete( el, tail(l1) );

Eliminazione di un elemento

Operazioni non primitive

list insOrd(list l1, listData x){

if ( l1.empty() ) return nl.addFirst( x );

if ( x.less( l1.head() ) return l1.addFirst(x);

else return insOrd( l1.tail(),x).addFirst(x);

}//insOrd

Classi astratte

Introdotte come specifiche (operazionali) Non possono essere istanziate Devono essere specializzate da sottoclassi Possono includere operazioni non primitive

Wrapping

Tecnica usata per organizzare in Java il sottosistema di I/O

Principi OOP A.Natali Aprile 19991 Principi di oop Dai costrutti alle metodologie.

Documents

Transcript of Principi OOP A.Natali Aprile 19991 Principi di oop Dai costrutti alle metodologie.

OOP with C#

C. Vallati -- Bioinformatica OOP - Object Oriented Programming · C. Vallati -- Bioinformatica OOP - Object Oriented Programming •Python linguaggio versatile, supporta, sia programmazione

Programmazione ad oggetti. OOP La programmazione orientata agli oggetti (Object Oriented Programming) ha lobiettivo di formalizzare gli oggetti del mondo.

ROSSI 19991. UN GRUPPO DI MMG HA DISCUSSO SU CASI CLINICI DI CRISI IPERTENSIVE (VERE O PRESUNTE)

Introduzione alla programmazione ad oggetti in C++ Object Oriented Programming, OOP E.Mumolo. DEEI mumolo@units.it.

Progettazione SW - 15 introduzione a java come linguaggio oop. lezione 5

PROGRAMMAZIONE A OGGETTI (OOP) Lezione 8 prj …elearning.cardano.pv.it/e-learn/courses/MESAPROJECT/document/... · PROGRAMMAZIONE A OGGETTI (OOP) Lezione 8 prj Mesa (Prof. Ing N.

Lezione - unict.it Ponti... · Designer’s guide to Eurocode 1: EN 19991-2, EN 1991-1.1 -1-3 to -1-7 and EN 1990 Annex A2 2010 Thomas telford ISBN: 0-7277-3158-6

Principi della programmazione orientata agli oggetti · 2° fase: OOD: Object Oriented Design 3° fase: OOP: Object Oriented Programming La fase di analisi (OOA) consiste nel creare

Contrasto alle fake news e tutela della democraziadirittifondamentali.it/wp-content/uploads/2019/06/I.-Spadaro-Contras… · legge costituzionale n. 1/19991, nel riscrivere l’art.

2018 Programmazione a oggetti parte 3 - OOP @ PoliTo

W. THOROSSIAN 21-04-2004. Argomenti: Antenne – principi generali Antenne – principi generali Radio modem – principi ed applicazioni Radio modem – principi.

Object-OrientedProgramming (OOP) · PDF file• PHP CSI 3125, History, page 14. Computer LanguagesHistory ... Perchè OOP? Sviluppo di componenti in parti distinte DISIM -Dipartimento

SSIS VENETO Didattica della OOP mediante la tartaruga LOGOmarin/docs/oop-logo.pdf · • frattali • ereditariet´a • ... tesi: • il valore ... so indietro e focalizzare per

Sistemi Operativi - oop-at-disi.github.io · • Terza generazione: 1965-1980 – sistemi basati su circuiti integrati – sistemi batch multi-programmati • Quarta generazione:

Progettazione SW - 13 introduzione a java come linguaggio oop. lezione 3

Presentazione primi principi oop

Presentazione principi oop

Corso OOP & OOD

Java - 02 - Il Linguaggio (senza OOP) · JAVA Funzioni DIAPOSITIVA 18 ALESSANDRO URSOMANDO FUNZIONI JAVA Funzioni $ ˘ public static NomeFunzione ()