CAPITOLO 3

1. CAPITOLO 3 ELEMENTI DI PROGRAMMAZIONE OBJECT-ORIENTED

2. 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"

3. 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]

4. 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

5. 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

6. 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

7. (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")

8. 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à

9. 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")

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

11. 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

12. 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.

13. 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

14. 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"

15. 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

16. "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

17. 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

18. 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]