CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

18
CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT- ORIENTED

Transcript of CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

Page 1: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

CAPITOLO 3

ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED

Page 2: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

PROBLEMI DEL SOFTWARE

• Quantità sempre maggiori (informatizzazione)

• Sempre più complesso (e struttura non ovvia)

• Difficile da specificare (redazione "capitolati")

• Difficile costruirne di affidabile (robustezza)

• Difficile da collaudare (esaustività dei test)

• Difficile rimozione dei guasti (manutenibilità)

• Soggetto a continue modifiche (evoluzione)

• Modello di produzione "diffusa" (integrazione)

• Intrattabile con metodologie "centralistiche"

Page 3: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

OGGETTI: CHE SONO MAI?

• Versione informatica degli oggetti "reali"

• Dotati di una loro propria "individualità"

• Capaci di interagire per scambio di messaggi

• Caratterizzati da proprietà (dati e funzioni)

• Data abstraction: proprietà "statiche" (stato)

• Functional abstraction: proprietà "dinamiche" (astraggono il "comportamento" dell'oggetto)

• Un msg modifica stato e attiva comportamenti

• Un oggetto "è" una coppia [stato,funzioni]

Page 4: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

ESEMPIO: UN'AUTOMOBILE

• Functional abstraction– Avvìati

– Férmati

– Gira a destra

– Gira a sinistra

• Data abstraction– Colore

– Velocità

– Rotazione volante

– Livello carburante

– Ultima revisione

Page 5: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

INCAPSULAMENTO

• Associazione oggetto-coppia [stato,funzioni]

• Permette di "nascondere" aspetti della coppia

• Alcuni attributi sono visibili "all'esterno"

• Altri attributi sono "privati" dell'oggetto

• Le parti private sono reimplementabili senza implicazioni per gli interlocutori dell'oggetto

• Propagazione delle modifiche assai contenuta

• Stimolo al riutilizzo di oggetti ("black-box")

• Nascita di un'industria di componenti SW

Page 6: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

ESEMPIO: AUTOMOBILE

• Parti "visibili" (interfaccia pubblica): accesso a "ciò che l'auto può fare"– volante, combinazione volante-freno (ev. a mano)

– blocchetto di accensione, oppure manovella

– pedale dell'acceleratore, acceleratore automatico

• Parti "nascoste" (implementazione): "come l'auto fa ciò che si può fare"– meccanica dello sterzo e dell'alimentazione

– elettromeccanica dell'avviamento

– sistema di alimentazione e accensione

Page 7: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

(IN)VISIBILITA' E PUREZZA

• L'implementazione può essere cambiata a parità di interfaccia pubblica– presenza o meno del servosterzo

– motorino di avviamento o piccola carica di dinamite

– accensione elettromeccanica o elettronica

• Approccio "puro": lo stato è privato, e lo si può modificare solo attraverso l'uso di quelle componenti funzionali che sono state dichiarate pubbliche (es. "férmati")

• Approccio di Java: anche le componenti dello stato possono essere dichiarate pubbliche e modificate dall'esterno (es. "velocità=0")

Page 8: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

INTERAZIONI TRA OGGETTI

• Gli oggetti possono comunicare e interagire mediante scambio di messaggi attraverso le loro interfacce pubbliche (stato o funzioni)

• Per mezzo di un messaggio un oggetto può chiedere un'informazione a un altro oggetto, causarne un cambiamento di stato, oppure delegargli un'attività

• Un messaggio in arrivo viene trattato dal metodo omonimo del ricettore, il quale "si attiva" per rispondere, per cambiare di stato, oppure per intraprendere un'attività

Page 9: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

ESEMPIO: UN'AUTOVETTURA

• Il sistema antiskid durante una frenata invia periodicamente un messaggio alle ruote per "leggere" la loro velocità di rotazione

• Il galleggiante nel serbatoio del carburante invia messaggi all'indicatore di livello sul cruscotto per "scrivervi" un nuovo stato

• Il volante tornando alla posizione di riposo invia un messaggio al comando meccanico dell'indicatore di direzione per delegargli il compito di interrompere l'eventuale segnale lampeggiante (i.e. di "togliere la freccia")

Page 10: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

CLASSI

• Visione "naturalistica" più che "insiemistica": insiemi di oggetti (gli esemplari della classe) aventi identica struttura (stato composto di identici attributi, identico comportamento)

• Specificano sia le componenti dello stato (nome e tipo, ma non necessariamente il valore) che le operazioni possibili (non solo nome e tipo, ma anche il comportamento)

• Due esemplari di una stessa classe sono distinguibili solamente per il valore dei loro attributi (il comportamento è sempre identico)

Page 11: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

SOTTOCLASSI E SOPRACLASSI

• Sono rispettivamente la specializzazione e la generalizzazione di una classe per variazione del numero dei membri e/o per loro modifica

• Una sottoclasse si ottiene per aggiunta, per occultamento o per ridefinizione di uno o più membri rispetto alla classe di partenza (che diventa una sopraclasse della nuova classe)

• Gli oggetti della sottoclasse non "sanno" se sono nativi o se sono derivati da sopraclassi

• NOTA BENE: in funzione del problema, sono possibili più tassonomie diverse, così come avviene nelle scienze naturali

Page 12: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

ESEMPIO: L'AUTOMOBILE

• La classe "automobile" è generalizzabile alla sopraclasse "veicolo a motore", a sua volta generalizzabile alla sopraclasse "veicolo", a sua volta, generalizzabile alla classe "mezzo di trasporto", a sua volta ... (omissis) ... a sua volta generalizzabile alla classe "oggetto"

• Oppure è specializzabile alla sottoclasse "berlina", a sua volta specializzabile alle sottoclassi "segmento A", "segmento B", etc.

• Alternativamente, la classe "berlina" può essere specializzata alle sottoclassi "diesel", "a benzina", "elettrica", "a reazione", etc.

Page 13: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

EREDITARIETA'

• E' il meccanismo di specializzazione che consente di derivare una sottoclasse (N.B.: non una sopraclasse!) da una classe data

• Consente quindi il "riutilizzo programmabile"

• Le componenti della classe originale vengono conservate nella classe derivata, a meno che in quest'ultima non vengano esplicitamente occultate (p.es. perché ritenute irrilevanti o "dannose") o ridefinite (p.es. perché se ne può fornire un'implementazione migliore)

• Alle componenti della classe data se ne possono aggiungere altre a piacimento

Page 14: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

ESEMPI: GUI, MATRICI E 740

• Implementazione di un'interfaccia grafica– classe "finestra": attributo privato "sfondo" e metodo

"cambia-sfondo"

– sottoclasse "finestra-nera": attributo privato "sfondo" ridefinito con il valore costante "nero", metodo "cambia-sfondo" occultato

• Libreria di algebra lineare:– classe "matrice": metodo "determinante" generico

– sottoclasse "matrice-diagonale": metodo "determinante" che moltiplica tra di loro gli elementi sulla diagonale

• Compilatore della dichiarazione dei redditi– classe "contribuente": quadri del modello 740 base

– classe "autonomi": aggiunta del membro "quadro-E"

Page 15: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

EREDITARIETA' MULTIPLA

• Insieme di meccanismi (la letteratura non è univoca) che consentono di derivare nuove sottoclassi da due o più (sopra)classi

• Esempio: due resistenze in serie possono essere viste come esemplare della classe "circuito" (o magari "circuito-serie-parallelo") o come esemplare della classe "resistenza"

• Porzioni di codice diverse possono scegliere di trattare un oggetto secondo l'una o l'altra "vista", specificando qual'è la scelta corrente

• Java non implementa ereditarietà multipla

Page 16: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

"NANETTO" DI PAOLO ERCOLI

Al chiar.mo prof. Paolo Ercoli

Direttore del Centro di Calcolo

Sede

Roma, 1.4.87

Caro Ercoli,

nella mia qualità di presidente del corso di

laurea in Ingegneria Informatica mi trovo a

lamentare il disservizio... (omissis) ...

Con i migliori saluti.

Paolo Ercoli

Page 17: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

CLASSI ASTRATTE

• Create per generalizzazione, rappresentano descrizioni "incomplete" di oggetti

• Raccolgono alcune delle loro caratteristiche comuni, ma non in quantità sufficiente a farne delle vere e proprie superclassi

• Pertanto non posseggono esemplari ("non possono essere istanziate"), ma è possibile derivarne sottoclassi "vere" (i.e. non astratte)

• Usate principalmente come strumenti di polimorfismo per definire operazioni (e.g. "print") comuni a più classi poco correlate

Page 18: CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED.

TERMINOLOGIA E SINONIMI

• Classi o tipi– generalizzazione, specializzazione o raffinamento

– sottoclasse o figlia, sopraclasse (o superclasse) o madre o classe base, classe astratta

– ereditarietà [ingl. "inheritance"], gerarchia o tassonomia di classi

• Oggetti o attori– esemplare [gerg. "istanza", da "instance"] di una classe

– componente o membro o proprietà

• Funzioni o operazioni– astrazione funzionale o comportamento (behaviour)

– componente pubblica o interfaccia o metodo

• Dati o attributi– stato [il termine "data abstraction" è mal traducibile]