PROGRAMMAZIONE AD OGGETTI GENERALITA’
GLOSSARIO
Affidabilità Garbage Collector Oggetto
Campi Incapsulamento Paradigma
Classe Information hiding Polimorfismo
Debug Istanza Riusabilità
Ereditarietà Metodi U.M.L.
Il problema della produzione del software, come per ogni altro settore commerciale, è quello di avere dei prodotti di qualità a costi contenuti. Quello che caratterizza la produzione software è il fatto che i costi che incidono maggiormente sono quelli necessari alla manutenzione di un prodotto, intesa sia come interventi rivolti a migliorare l’affidabilità (la rimozione degli errori, la gestione dei casi imprevisti, ecc., in gergo il debug), sia rivolta a soddisfare le inevitabili nuove esigenze che si vengono a creare durante l’esercizio del software stesso. Per quanto riguarda l’affidabilità, il modo migliore per ridurre i costi di manutenzione è quello di impedire sul nascere i malfunzionamenti, cercando di produrre sin dall’inizio software corretto. Nonostante ciò, una volta che si dispone di software affidabile, è lo stesso committente che richiede di modificarlo per tenere conto di nuove esigenze, riesponendolo così al rischio di nuovi errori. Si è sentita quindi l’esigenza di poter apportare modifiche al software riutilizzando al massimo il codice già esistente, nonché sfruttando codice già scritto (riusabilità). Fin dai primi anni ’80, molti produttori di software, alla costante ricerca di metodologie in grado di ridurre i costi di produzione e manutenzione, hanno individuato nella cosiddetta programmazione orientata agli oggetti (Object Oriented Programming, OOP) una buona soluzione per questi problemi. Per cercare di capire la “filosofia” della OOP si partirà da una domanda che superficialmente sembra non aver nulla a che vedere con la programmazione: come sono riuscite aziende quali Compaq, Dell, Gateway, Micron Technologies e le altre principali case costruttrici di personal computer a diventare tanto grandi in così breve tempo? Come sono riuscite a fabbricare così tanti modelli tanto rapidamente, rispondendo così tempestivamente alle modifiche in atto? Una parte consistente della risposta è che queste società hanno affidato all’esterno una quota cospicua del lavoro. Esse hanno acquistato componenti da produttori affidabili e li hanno quindi assemblati. In genere non hanno investito tempo e denaro nella progettazione e costruzione di alimentatori, unità a disco, schede di sistema ed altre componenti. Questo ha consentito loro di essere più efficienti di quanto sarebbe stato possibile se avessero provveduto direttamente alla ingegnerizzazione. In un certo senso, la più nuova delle teconolgie, aveva “riscoperto” l’efficacia della suddivisione del lavoro (Fordismo).Quello che le case costruttrici di computer acquistavano era una ”funzionalità precostituita”. Per esempio, quando acquistavano un alimentatore, acquistavano determinate proprietà (dimensioni, forma, ecc.) e determinate funzioni (regolarità dell’alimentazione, quantità di alimentazione disponibile, ecc.). La programmazione ad oggetti nasce dalla stessa idea. Il programma è costituito da oggetti, con determinate proprietà e operazioni che gli oggetti possono svolgere.
Alla base del paradigma della OOP c’è quindi il concetto di oggetto. La nozione di oggetto nella OOP corrisponde per alcuni aspetti, a quella – che tutti noi possediamo – degli oggetti materiali. Per esempio in fig.1 l’oggetto “fattura” (dal punto di vista dell’implementazione ) ha delle proprietà (variabili di istanza o campi) quali: “numero” contiene il numero della fattura, “intestatario”, “importo”, ecc. e delle operazioni (metodi) quali: “mostra” che visualizza la fattura, “archivia”, “elimina”, ecc.
Proprietà/Campi Operazioni/Metodi Numero
fattura Visualizza Intestatario Archivia Importo Elimina … … … … Fig. 1
L’oggetto Fattura
Potremmo pensare ad un generico oggetto OOP come a “una scatola nera”, il cui involucro presenta un’ interfaccia con l’esterno idealmente divisa in due sezioni:
· quella dei metodi (insieme delle operazioni che l’oggetto può svolgere)
· quella delle proprietà o stato dell’oggetto (valori delle variabili di istanza o campi).
L’involucro assolve a due importanti funzioni di protezione:
· protezione dell’utente dall’oggetto, intendendo con ciò che all’utente vengono nascosti tutti i meccanismi utilizzati dall’implementatore per la realizzazione dell’oggetto. Ciò ha l’effetto di semplificare al massimo l’uso dell’oggetto stesso consentendo all’utente di avere una visione astratta dell’oggetto. Si immagini che difficoltà potrebbe avere un utente nel cambiare il volume di un televisore senza involucro agendo direttamente sui circuiti interni.
· Protezione dell’oggetto dall’utente (incapsulamento), intendendo con ciò che l’utente può accedere all’oggetto solo attraverso i comandi previsti dall’implementatore. Riprendendo l’esempio precedente, si immagini a quali rischi verrebbe sottoposto il televisore se si consentisse ad un utente di agire liberamente su un televisore privo di involucro.
Questa funzione dell’involucro, che appare banale e scontata, è stata in realtà una conquista relativamente recente dell’ingegneria del software ed è denotata spesso con l’espressione information hiding (occultamento di informazioni). Per molto tempo si è infatti ritenuto che il libero accesso a tutti i meccanismi e le informazioni fosse un elemento di vantaggio per i programmatori in virtù della grande flessibilità che veniva offerta nel proporre e nel modificare la propria soluzione. In realtà essa toglie capacità di astrazione e rende minima l’affidabilità del sistema. Come accennato in precedenza, nella OOP il programma è un insieme di oggetti con determinate proprietà e metodi interagenti tra loro. In questo contesto, l’interazione tra due oggetti viene descritta in termini di messaggi. Quando un oggetto A deve utilizzare una funzionalità di un altro B, si dice che A invia un messaggio a B. In realtà ciò che accade è che attiva o chiama un metodo di B. In questa relazione A si pone nei confronti di B come un utente di un servizio, mentre B diventa il fornitore, perciò si dice che A è un oggetto client e B server. Costruendo gli oggetti in modo tale che gestiscano tutti i messaggi appropriati e manipolino i dati solo internamente(incapsulamento), si aumenta al massimo la possibilità di riutilizzo del software e si riduce al minimo il tempo di debug. Questa, è la soluzione data dagli ingegneri del software alle problematiche evidenziate all’inizio.
