Principi della programmazione orientata agli oggetti

Un problema che ha sempre assillato il mondo dell'informatica È quello di poter facilmente eseguire la manutenzione dei programmi, compito la cui difficoltÀ cresce al crescere della dimensione del codice.

Agli albori dell'informatica i programmi erano piccoli, non tanto perché i calcolatori di 30-40 anni fa erano assai meno potenti di un odierno PC, ma perché il linguaggio di programmazione di allora era l'assembler. Chiunque si sia cimentato a scrivere codice assembler avrÀ notato che il principale difetto di questo linguaggio È quello di produrre un codice sorgente non facilmente comprensibile e di grosse dimensioni anche per fare la cosa piÙ semplice.

Da allora sono stati sviluppati nuovi linguaggi e paradigmi di programmazione che consentono un maggiore livello di astrazione e una piÙ facile comprensione del codice prodotto: un esempio È dato dai linguaggi procedurali quali il Pascal; questi linguaggi implementano la metafora della scatola nera: un blocco di codice la cui complessitÀ È racchiusa al proprio interno e che non produce alcun cambiamento nel mondo esterno ad esso (effetti collaterali). Essi tuttavia, pur avendo introdotto concetti ancora validi, hanno mancato l'obbiettivo principale, perché i loro progettisti fecero inconsciamente l'assunzione che una scatola nera una volta chiusa non va riaperta, cioÈ quando che un blocco di codice È stato realizzato ed È funzionante, non va piÙ modificato.

Sia a causa di questa assunzione, sia perché i programmatori non rispettavano alla lettera il paradigma della programmazione procedurale, si ebbe tra la fine degli anni '60 e l'inizio degli anni '70 la 'crisi del software': nessuno voleva piÙ occuparsi di manutenzione.

Per migliorare il supporto che i linguaggi procedurali fornivano alla fase di manutenzione venne poi introdotto il concetto di sviluppo strutturato, che richiede una attenta pianificazione di ciÒ che si voleva realizzare e la produzione di una buona documentazione che descriva il funzionamento del sistema. Ma come ben si sa, quello che spesso accade È che si pensa a scrivere il codice, rimandando ad un successivo momento o ad altri la stesura della documentazione, con il risultato che nella migliore delle ipotesi la documentazione prodotta È inadeguata allo scopo per cui essa È stata realizzata. In sostanza, pur avendo prodotto molte utili tecniche, anche lo sviluppo strutturato si È rivelato poco efficace dal punto di vista della manutenzione del software; occorreva fare un ulteriore passo in avanti: la programmazione orientata agli oggetti.

Questo paradigma di programmazione ha introdotto molti nuovi concetti che hanno letteralmente rivoluzionato tutti (o quasi) i campi dell'informatica (e questi hanno influenzato la programmazione orientata agli oggetti). Prima di proseguire e di introdurre i concetti base della OOP (Object Oriented Programming) È bene fare una precisazione: pur essendo stata teorizzata per la prima volta parecchi anni fa, la OOP È lontana dal possedere uno standard di riferimento, tanto È vero che su molti concetti non esiste alcun accordo tra i teorici di questa disciplina, per cui non stupitevi se qualcun altro definirÀ un concetto in maniera piÙ o meno diversa da quanto verrÀ fatto tra poco.

La caratteristica piÙ rivoluzionaria dei linguaggi ad oggetti È quella di concepire i dati e le operazioni su di essi come una unica cosa (oggetto), e non entitÀ separate (dopo tutto dati e operazioni su di essi sono in qualche modo correlati).

Una definizione formale direbbe che un oggetto È una entitÀ software dotata di stato, comportamento e identitÀ. Lo stato viene modellato con costanti e/o variabili dette attributi dell'oggetto; il comportamento È dato da procedure locali dette metodi (alcuni non fanno alcuna distinzione tra attributi e metodi, utilizzando unicamente il primo termine); infine l'identitÀ È qualcosa di unico, immutabile e indipendente dal valore dello stato, che rende un oggetto diverso da ogni altro.

Un oggetto comunica con il mondo esterno tramite messaggi; un messaggio altro non È che una operazione che puÒ essere compiuta su quell'oggetto e l'insieme dei messaggi a cui un oggetto risponde ne costituisce l'interfaccia. Alcune precisazioni: le componenti di uno stato possono essere valori elementari o complessi quali record, oggetti, liste di tipi elementari o oggetti e cosÌ via; in generale la OOP prevede che gli attributi di un oggetto non siano mai accessibili dall'esterno, quando ciÒ accade si dice che l'oggetto incapsula lo stato. Altra caratteristica di un oggetto È quella di possedere una identitÀ che permane nel tempo e che distingue sempre due oggetti: come due gemelli pur essendo fisicamente identici non sono la stessa persona, cosÌ due oggetti pur avendo uguali il valore dello stato, il comportamento e l'interfaccia non sono mai uguali; se due oggetti sono uguali allora sono lo stesso oggetto.

Il concetto di messaggio consente l'astrazione dai dati: il programma che usa un oggetto non ha alcuna necessitÀ di conoscerne la struttura interna, per compiere una operazione su di esso tutto quello che deve fare È inviargli un messaggio a cui l'oggetto risponderÀ restituendo uno o piÙ valori memorizzati nel suo stato o calcolati da esso mediante alcuni dei suoi metodi; ciÒ consente di cambiare la rappresentazione interna dell'oggetto senza dovere modificare anche i programmi che usano quell'oggetto, che invece continueranno a funzionare regolarmente.

Inviare un messaggio ad un oggetto È possibile grazie ad un costrutto del tipo SEND oggetto arg1 arg2 argN; questo in pratica equivale ad un nuovo meccanismo di chiamata di procedura (si chiama una procedura dell'oggetto: quella relativa al messaggio inviato). CiÃ’ benché sia semanticamente diverso dal chiamare una procedura qualsiasi, tende secondo alcuni a rendere le cose piÙ difficili e di fatto molti linguaggi implementano il meccanismo dei messaggi nello stesso modo in cui sono implementati i metodi; l'unica differenza tra un metodo ed un messaggio È che il primo È locale (privato) all'oggetto, mentre il secondo non lo È (pubblico). Nel seguito, al fine di eliminare possibili incomprensioni, faremo distinzione tra attributo, metodo e messaggio.

Per poter creare un oggetto È necessario definire ciÒ che lo caratterizza, È cioÈ necessario dare una definizione di tipo oggetto. Un tipo oggetto definisce come minimo l'interfaccia di un insieme di possibili oggetti, ma per molti linguaggi dichiarare un tipo oggetto vuol dire definire la struttura dello stato, l'insieme dei metodi, l'interfaccia e implicitamente (almeno) un costruttore e (almeno) un distruttore.

Costruttori e distruttori sono procedure che il linguaggio usa per creare e rimuovere gli oggetti di cui il programma necessita; in generale costruttori e distruttori vengono realizzati dal linguaggio stesso sulla base della definizione data, ma viene sempre consentito al programmatore di specificare altre operazioni (per ciascun costruttore e distruttore) che questi devono intraprendere quando vengono invocati.

A questo punto puÒ sorgere una domanda: distruggere un oggetto che al proprio interno racchiude un altro oggetto non pone alcun problema (non È necessario distruggere anche quest'ultimo, a meno che il programmatore non specifichi altrimenti), ma cosa succede nel caso contrario?

La risposta a questa domanda È dipende: se quella componente dello stato puÒ assumere il valore indefinito, non ci sono problemi, altrimenti È necessario distruggere anche l'oggetto piÙ grosso, iterando automaticamente il procedimento (in quei linguaggi che trattano gli oggetti indipendentemente dalla loro complessitÀ), oppure lasciando al programmatore il compito di eseguire esplicitamente la distruzione di tutti gli oggetti dal piÙ piccolo al piÙ grosso (tutto dipende dal fatto che il linguaggio tratti gli oggetti come un tutt'uno, indipendentemente dalla loro complessitÀ, o meno). Il motivo di tutto ciÒ È semplice, dato che un oggetto possiede una identitÀ unica, assegnarlo ad un campo di un altro oggetto non vuol dire copiarlo in quel campo, ma attivare un riferimento all'oggetto assegnato; ciÒ implica che in seguito alla distruzione dell'oggetto tutti i riferimenti ad esso divengono non validi e un tentativo di accedere all'oggetto distrutto genera un errore a tempo di esecuzione. Molti linguaggi object oriented non offrono alcun modo di verificare ciÒ, lasciando al programmatore il compito di assicurarsi della corretta creazione e distruzione degli oggetti.

Un altro importante concetto della OOP È quello di ereditarietÀ. Supponiamo di aver definito un tipo Persona e di aver bisogno anche di un tipo Studente, in fondo uno studente È sempre una persona, anche se con delle caratteristiche in piÙ: oltre agli attributi ed ai metodi di una persona, possiede una matricola, si iscrive ecc. Tutto questo un linguaggio non orientato agli oggetti non consente di esprimerlo con facilitÀ, ne tanto meno di farlo senza dover riscrivere parte del codice del tipo Persona nel tipo Studente;

in un linguaggio ad oggetti invece ciÒ si fa dichiarando il tipo Studente discendente del tipo Persona, in tal modo il tipo Studente (detto tipo figlio e in generale sottotipo) eredita tutti gli attributi e i metodi del tipo Persona (tipo padre e in generale supertipo), bisognerÀ poi dichiarare solo ciÒ che È proprio del tipo Studente aggiungendo nuove definizioni e/o sovrascrivendone alcune del tipo padre.

Naturalmente il tipo figlio eredita dal padre anche l'interfaccia. L'ereditarietÀ È quindi un meccanismo innovativo che consente il reimpiego di codice precedentemente scritto; si noti inoltre che tale concetto stabilisce una gerarchia tra i tipi: in cima sta quello definito per primo, poi quelli definiti a partire da questo e via via iterando ai livelli successivi al primo (naturalmente si tratta di una relazione di ordinamento parziale).

Se la ridefinizione di un attributo È consentita solo per specializzazione si dice che l'ereditarietÀ È stretta, altrimenti si parla di ereditarietÀ debole; se un linguaggio implementa l'ereditarietÀ stretta, lÀ dove È richiesto un supertipo puÒ essere utilizzato un sottotipo (in quanto il sottotipo 'riempie' completamente il supertipo), si ha cioÈ anche l'ereditarietÀ del contesto, ciÒ invece non È vero in caso di ereditarietÀ debole, in questo caso vale solo che il sottotipo risponde anche ai messaggi del supertipo.

La ridefinizione di un metodo puÒ riguardare tanto gli argomenti e il risultato, quanto l'implementazione stessa del metodo; se si ridefinisce l'implementazione del metodo, in quella nuova È possibile eseguire una chiamata allo stesso metodo come implementato prima (in questo modo si puÒ essere certi che i campi ereditati, se non ridefiniti, vengano manipolati correttamente, limitando cosÌ la possibilitÀ di errore).

L'ereditarietÀ stretta pone un problema: supponiamo di avere una procedura F(x:Persona) che chiami il metodo Presentati ridefinito nel sottotipo Studente, e siano Caio di tipo Persona e Tizio di tipo Studente; la chiamata ad F(Caio) È del tutto lecita e non comporta problemi, ma la chiamata ad F(Tizio), lecita perché in presenza di ereditarietÀ del contesto, quale metodo Presentati chiamerÀ? Quello relativo al tipo Persona o al tipo Studente? Questo problema viene risolto chiamando sempre il metodo piÙ specializzato tramite la tecnica di collegamento ritardato (late binding) che rinvia a tempo di esecuzione la scelta del metodo da applicare e quindi F(Tizio) chiamerÀ il metodo Presentati relativo al tipo Studente.

Ovviamente ciÃ’ puÃ’ non essere gradito, ad esempio perché il metodo restituisce qualcosa in piÙ che non vogliamo; per risolvere tale problema tutti i linguaggi ad oggetti consentono di forzare la chiamata del metodo relativo al tipo dell'argomento.

Chiaramente se un sottotipo non ridefinisce un metodo, una chiamata ad esso viene risolta chiamando l'implementazione che per prima si incontra risalendo la gerarchia dei tipi (relativa a quel tipo), generando un errore se tale metodo non e stato definito.

Il concetto di ereditarietÀ puÒ essere esteso in modo tale da consentire ad un tipo oggetto di ereditare da piÙ supertipi, distinguendo cosÌ tra ereditarietÀ semplice ed ereditarietÀ multipla. Non tutti sono favorevoli all'ereditarietÀ multipla, molti sostengono che ciÒ che essa consente È ottenibile anche con l'ereditarietÀ semplice; entrambe le fazioni hanno validi motivi a sostegno delle proprie idee: molte situazioni che in passato richiedevano l'ereditarietÀ multipla oggi sono risolvibili utilizzando opportune tecniche, ma in alcune situazioni l'ereditarietÀ multipla È ancora la situazione migliore: tipicamente quando si vogliono combinare le caratteristiche di piÙ tipi per ottenere un sottotipo piÙ flessibile: ad esempio un tipo FileDiInput ed un tipo FileDiOutput combinati insieme per ottenere un tipo FileDiInputOutput. A fronte di questi vantaggi l'ereditarietÀ multipla pone tuttavia un problema di ambiguitÀ quando due o piÙ tipi utilizzano lo stesso identificatore, in questi casi bisogna disporre di uno strumento per risolvere il problema: ad esempio una soluzione (troppo restrittiva) potrebbe semplicemente impedire che la cosa accada; inoltre È molto piÙ difficile gestire bene una gerarchia di tipi in presenza di ereditarietÀ multipla.

Il meccanismo dell'ereditarietÀ nasconde un'altra importante possibilitÀ che va oltre la riusabilitÀ del codice: il polimorfismo. La possibilitÀ di avere oggetti diversi con la stessa interfaccia (o parte di essa) consente di realizzare applicazioni capaci di utilizzare correttamente oggetti di diverso tipo senza alcuna distinzione: supponiamo di voler realizzare una applicazione che tracci e cancelli poligoni di varie forme, quello che bisogna fare È dichiarare un tipo Poligono che risponda ai messaggi TRACCIA e CANCELLA e poi derivare da esso i tipi Triangolo, Quadrato ecc. i quali risponderanno ancora ai messaggi del supertipo, ma in maniera diversa. Il nostro programma non dovrÀ fare altro che gestire il solo tipo Poligono limitandosi a inviare ad esso solo i messaggi a cui risponde, sarÀ poi l'oggetto in questione che penserÀ a tracciarsi o cancellarsi.

Programmi cosÃŒ fatti possono facilmente essere estesi senza dover letteralmente toccarne l'implementazione, basta aggiungere nuovi tipi derivandoli dal supertipo che sta in cima alla gerarchia. La possibilitÀ di avere oggetti polimorfi, che quindi si comportano in maniera differente (secondo il loro tipo effettivo) ha non a caso dato ai linguaggi ad oggetti il soprannome di 'linguaggi attori', proprio perché come un attore un oggetto puÃ’ 'recitare' ruoli diversi a seconda della situazione.

Una utile estensione al paradigma ad oggetti visto finora (molto utile nel campo delle basi di dati) È il concetto di classe; una classe È un insieme di oggetti dello stesso tipo con associati operatori per estrarre, inserire e cercare elementi di quel tipo. Anche per le classi come per i tipi oggetto si parla di gerarchia: una classe C2 si dice sottoclasse di C1 se il tipo T2 degli elementi di C2 È sottotipo di T1, tipo di C1 (vincolo intensionale); ciÒ comporta che gli elementi di C2 sono anche elementi di C1 (vincolo estensionale), cioÈ C2 È un sottoinsieme di C1 (ricordate? un oggetto di un tipo È anche un oggetto di ogni suo supertipo).

Spesso si parla anche di metaclassi, intendendo con questo termine una classe i cui elementi sono altre classi.

Fate attenzione al fatto che in molti linguaggi (compreso il C++) il termine di classe È usato come sinonimo di tipo e quindi non ha niente a che vedere con la definizione di prima; in tali linguaggi puÒ divenire difficile gestire gli oggetti di un tipo, specie se ce ne sono molti; in questi casi purtroppo il programmatore non dispone di alcun aiuto e deve programmarsi una opportuna struttura e gli operatori su di essa.

Un'altra estensione prevede che gli oggetti possano assumere e perdere dinamicamente ruoli, rispettivamente trasformandoli in un oggetto del sottotipo o riportandoli ad un supertipo. Tutto questo nasce dalla constatazione che nella realtÀ le entitÀ assumono e perdono delle caratteristiche: ad esempio una persona salendo su un'auto diviene passeggero o automobilista, scendendo ritorna ad essere un pedone. Ancora una volta non tutti i linguaggi offrono tale possibilitÀ.

Benché la OOP abbia risolto diversi problemi, non ha centrato tutti gli obbiettivi: la riusabilitÀ del codice È una realtÀ locale alla singola applicazione, È assai difficile che il codice di una applicazione possa essere facilmente utilizzato in un'altra: la cosa È fattibile solo relativamente a oggetti e tools di applicazione generale, in quanto spesso È necessario apportare grosse modifiche al codice giÀ disponibile, al punto che È piÙ conveniente ricominciare da capo.

Tuttavia È innegabile che la manutenzione del software sia oggi molto piÙ semplice di quanto lo fosse una volta, ma È necessario uno studio approfondito del sistema da realizzare, scrivere del codice il piÙ possibile autoesplicativo e naturalmente PENSARE AD OGGETTI.