Diciannovesima lezione

Ci siamo finora concentrati sulle caratteristiche e funzionalità del nuovo linguaggio che abbiamo imparato, e sulle sue (vaste!) potenzialità di utilizzo. Non ci siamo chiesti se ci possano essere margini per migliorare o ripensare il nostro metodo di analisi dei problemi e di programmazione, indipendentemente dal linguaggio scelto.

A dir la verità può darsi che non sentiamo neanche la necessità di un miglioramento in questo campo, e questa obiezione è sostanzialmente fondata finché la complessità dei problemi, e dei sistemi informativi che li affrontano, rimane "piccola" (cioè confrontabile con quanto un singolo analista o programmatore possa trattare).
Sappiamo tuttavia (e ci ricolleghiamo a quanto detto nella lezione introduttiva) che la natura dei problemi reali da affrontare, ormai anche nel campo della ricerca scientifica, trascende largamente le potenzialità di un singolo sviluppatore, e richiede opportuni stratagemmi per tenere sotto controllo la complessità del progetto software, e le risorse (soprattutto umane) destinate ad affrontarla.

Uno di questi stratagemmi, coronato da un certo successo pratico nell'applicazione a grandi progetti, e quindi spesso riproposto e riutilizzato, consiste nell'analisi, progettazione e programmazione orientata agli oggetti (OO, in breve).
La prima importante distinzione da rilevare è quella fra il processo di analisi e progettazione OO, ed i linguaggi di programmazione OO (che implementano cioè alcuni dei meccanismi tipici richiesti dal modello OO, come vedremo fra un istante). E' infatti possibile scrivere codice OO senza usare un linguaggio OO, e scrivere codice procedurale (usiamo questo termine per indicare i "normali" metodi di programmazione non OO) utilizzando un linguaggio specializzato OO (come ad esempio il C++).
In sostanza l'impatto fondamentale del paradigma OO avviene prima della stesura del codice: nella fase di analisi e progettazione. Nei progetti software di grande dimensione, infatti, il tempo dedicato alla scrittura del codice non supera mai il 20 % circa del totale, (il tempo restante è ocupato dalla raccolta e analisi dei requisiti, dalla progettazione e soprattutto dal debugging).
I vantaggi offerti dal modello si riflettono nella migliore modularità del software prodotto (sono meglio definite le interfacce fra le varie componenti), nella maggiore facilità a riutilizzare algoritmi e strutture già scritte (si evita la duplicazione del lavoro), e nella maggiore facilità nel descrivere la struttura e la funzionalità del codice (rende più semplice il ricambio dei programmatori e garantisce una certa resistenza generazionale).

Si possono utilizzare vari approcci nel descrivere il modello ad oggetti. Uno dei più noti, utilizzato nel capitolo introduttivo del famoso libro di G. Booch, Object Oriented Analysis and Design (Addison-Wesley, 1994) si concentra sulle caratteristiche intrinseche del modello, valutando poi "se" un determinato linguaggio di programmazione può essere considerato OO oppure no. Un metodo alternativo potrebbe essere quello di identificare le caratteristiche che differenziano un linguaggio di programmazione OO da uno "non-OO". Entrambi i metodi danno in qualche modo per scontato "cosa" sia un oggetto. Partiremo dunque cercando di dare una definizione di "oggetto" (tenendo sullo sfondo le definizioni più precise di Booch), e gradualmente cercheremo, in modo molto pratico, di spostare la discussione sulle caratteristiche del linguaggio, arrivando ad identificare quelle caratteristiche di un linguaggio di programmazione OO che non riscontriamo nei linguaggi procedurali a cui siamo abituati.

Genericamente parlando, un oggetto può essere:

• Una cosa tangibile o visibile.
• Qualcosa che può essere compreso intellettualmente.
• Qualcosa verso cui si può dirigere il pensiero o l'azione.

Generalmente un oggetto è caratterizzato da uno stato, da un comportamento e da un'identità, come bene simboleggiato da questa illustrazione tratta, come quelle che seguono, da G. Booch, Object-oriented Analysis and Design:

Come trasportare questo concetto nel familiare ambiente delle strutture di dati?
Proviamo a partire con una definizione operativa, probabilmente sbagliata (o perlomeno molto limitata):

Un oggetto è una combinazione di strutture dati e procedure tali da realizzare una serie di funzionalità che possano essere attribuite astrattamente all'oggetto stesso.

Qualche tempo fa abbiamo fatto l'esempio delle funzioni di gestione dei grafici (graph_helper.c).
Nell'esempio erano presenti funzioni per creare un nuovo grafico (graph_create_new), per distruggere un grafico esistente (graph_free), per aggiungere nuovi punti (graph_add_point), per tracciare il grafico (graph_plot), per cancellare la finestra (graph_clear). Il "collegamento" fra queste funzioni era una struttura di dati che veniva creata assieme ad ogni grafico:

typedef struct graph_s
 {
  int cx, cy;    /* Center coordinates */
  int xal, yal;  /* Axis length in pixels */
  double dx, dy; /* Scale for 1 pixel along x and y */
  double xmax, xmin, ymax, ymin; /* Axis extremes */
  char lx[20],ly[20]; /* Axis labels */
  int nval;      /* Number of values in the graph */
  double *vx,*vy;/* Arrays of values */
  int wid;       /* ID of created window */
 } graph;

Ora, noi sappiamo che esistono anche i puntatori a funzione, e li abbiamo usati varie volte. Perché allora non associare alla struttura di dati anche le funzioni necessarie per operare sui dati stessi? Potremmo avere una definizione di questo tipo:

typedef struct graph_s
 {
  int cx, cy;    /* Center coordinates */
  int xal, yal;  /* Axis length in pixels */
  double dx, dy; /* Scale for 1 pixel along x and y */
  double xmax, xmin, ymax, ymin; /* Axis extremes */
  char lx[20],ly[20]; /* Axis labels */
  int nval;      /* Number of values in the graph */
  double *vx,*vy;/* Arrays of values */
  int wid;       /* ID of created window */
  int (*add_point)(graph *graph, double x, double y); /*Pointer to add_point*/
  void (*plot)(graph *graph, char *color); /* Pointer to plot function */
  void (*clear)(graph *graph);             /* Pointer to clear function */
  void (*free)(graph *graph);              /* Pointer to free function */
 } graph;

graph->plot(graph);

Già nel fatto che dobbiamo ripetere graph due volte si evidenzia come il C non sia un linguaggio OO (anche se permette, come in questo caso, qualche forma di programmazione OO). Il linguaggio C inoltre non può sapere come inizializzare automaticamente i puntatori a funzione quando un nuovo "oggetto" viene creato. Questa operazione va fatta a mano:

newgraph = (graph *)malloc(sizeof(graph));
(...)
newgraph->add_point = graph_add_point;
newgraph->plot = graph_plot;
newgraph->clear = graph_clear;
newgraph->free = graph_free;

Il C permette dunque, in qualche modo, di implementare la nostra definizione primitiva di oggetto, ma non altre caratteristiche che possono essere attribuite agli oggetti stessi. Grady Booch ne definisce principalmente quattro, che ora brevemente commentiamo:

• Abstraction: An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer..
  Questa è sostanziamente una ri-formulazione migliore della nostra definizione di partenza. Qui l'accento viene posto sul fatto che dati e procedure che costituiscono un "oggetto" devono distinguere l'oggetto da qualunque altro, devono cioè essere "scelte bene". Nel caso del nostro oggetto "grafico", queste caratteristiche di buona definizione sono rispettate. Questa definizione aggiunge però qualcosa in più, nell'ultima frase. La "visuale" che si ha di un oggetto può essere diversa, più o meno definita o articolata, a seconda dell'osservatore o dell'utilizzatore dell'oggetto stesso. Ecco un esempio di questo concetto:
  

• Modularity: is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.
  Questa è una proprietà fondamentale che il modello ad oggetti in qualche modo "costringe" ad utilizzare, ma che di fatto, come abbiamo visto fin dall'inizio, equivale alla richiesta di una buona qualità di programmazione. In qualsiasi linguaggio è di importanza fondamentale la capacità di comprendere in opportune funzioni o subroutine il "giusto" livello di generalità o di astrazione, in modo da ridurre al minimo il traffico di dati nella chiamata alle funzioni e semplificare le interfacce con le altre parti del sistema.
  La caratteristica degli oggetti di associare dati e "metodi" introduce un ulteriore elemento di semplificazione.

• Encapsulation: is the process of compartmentalizing the elements of an abstraction that constitute its structure and behaviour; encapsulation serves to separate the contractual interface of an abstraction and its implementation.
  Qui affiora un concetto nuovo: per realizzare le funzioni astratte assegnate ad un oggetto, non è necessario che chiunque possa "guardare dentro" (e magari modificare) le variabili interne all'oggetto utilizzate per realizzare le funzioni stesse. Anzi, questo può essere spesso dannoso o fuorviante. Nel nostro esempio "semplice", chiunque abbia in mano il puntatore di tipo graph * (normalmente utilizzato per "trasferire" un oggetto da un posto all'altro) può accedere a tutte le variabili della struttura. Alcune di queste variabili, però, appartengono ad un livello logico inferiore. Per esempio sarebbe meglio che le scale degli assi dx e dy, oppure il numero che identifica la finestra creata (wid) non venissero toccate dai livelli di codice superiori. In C non esiste un sistema per evitare che questo accada. Nel modello ad oggetti, è un requisito importante poter realizzare questa separazione di contesti.

• Hierarchy: is a ranking or ordering of abstractions.
  Una volta definito un livello di astrazione "giusto" (nel senso della definizione data sopra), si scopre che per gli oggetti reali possono esistere vari altri livelli di astrazione al di sopra o al di sotto di quello scelto. Per esempio il nostro oggetto graph ha la generica proprietà di poter essere disegnato, esattamente come un cerchio o una retta. graph disegna sostanzialmente una sequenza di punti, o poli-linea: una sua applicazione più particolareggiata potrebbe essere un oggetto che implementa gli stessi "metodi" di graph, ma permette di disegnare una generica funzione, dunque in qualche modo estende le funzionalità di graph. Si possono anche individuare altre "superclassi" o "sottoclassi" in relazione col nostro oggetto. La capacità di "estendere" le funzionalità di un oggetto non è facile da implementare in C: si dovrebbe definire una "nuova" struttura che contenga la vecchia, e la catena di richiami comincerebbe a diventare lunga (ad esempio function_graph->graph->plot(function_graph->graph);). Si rende dunque necessaria la capacità di ereditare semplicemente le funzionalità di un oggetto di gerarchia più generale:

Vediamo ora di riassumere le tre principali caratteristiche che un linguaggio di programmazione deve avere per soddisfare questi requisiti fondamentali del modello OO, e che non sono presenti nei normali linguaggi procedurali:

• Protezione del contenuto "privato" degli oggetti (Encapsulation). Abbiamo visto come questo sia uno dei requisiti fondamentali del modello OO. All'interno di un oggetto le strutture dati utilizzate devono poter essere contrassegnate a seconda della loro visibilità. I dati "privati" devono poter essere modificati soltanto dall'oggetto stesso.
  Sarebbe forse ragionevole che non fossero accessibili nemmeno i "metodi" di più basso livello dell'oggetto.

• Possibilità di ereditare struttura, funzionalità ed interfacce da altre classi (Inheritance). Il modo più pratico per esprimere le relazioni di gerarchia fra gli oggetti è permettere ad un oggetto di ereditare le proprietà (struttura e metodi) di un altro oggetto più generale. L'oggetto più generale può anche essere una semplice "scatola vuota" (oggetto virtuale) che definisce soltanto un'interfaccia, una serie di "metodi", che poi verranno "riempiti" dalle sottoclassi. In teoria (ma non tutti i linguaggi lo consentono) un oggetto può ereditare da più superclassi: pensiamo ad esempio a tutto ciò che accomuna tutti gli oggetti che possono essere disegnati, oppure tutti gli oggetti che possono essere rappresentati attraverso una sequenza di byte (questa ad esempio è la funzionalità è che permette di salvare e recuperare gli oggetti su disco, o di trasferirli via rete).

• Possibilità di attribuire funzionalità diverse a funzioni (metodi) con lo stesso nome (Polymorphism). Questa è una caratteristica che non discende direttamente dai requisiti del modello a oggetti, ma piuttosto ne è una conseguenza: manipolando oggetti, può venire spontaneo definire alcune "operazioni" che hanno lo stesso nome, ma che devono essere in pratica codificate in modo diverso se gli "operandi" cambiano. Pensiamo ad esempio alla "somma" (+): potrebbe essere utile definire degli oggetti per i quali ha senso un'operazione di somma (potrebbero essere numeri complessi, oppure quadrivettori spazio/tempo). Anche per il nostro oggetto graph potrebbe avere senso una somma che risulta nella concatenazione dei due grafici. I linguaggi OO consentono di determinare il comportamento di una funzione (o anche di un'operatore intrinseco come +) a partire dal tipo degli operandi.
  Questo polimorfismo (nel senso che una funzione con lo stesso nome si può comportare in modo diverso) semplifica la visione logica delle relazioni fra oggetti che si può esprimere nel codice.

Esistono vari linguaggi che aderiscono al paradigma OO che abbiamo cercato di tratteggiare. Questi linguaggi hanno un'evoluzione storica ed un dominio di applicazione molto vario:

Nell'ambiente della ricerca scientifica sono due i linguaggi OO che è più probabile incontrare:

• C++: Come il nome lascia intuire, è il frutto dell'applicazione al linguaggio C delle estensioni OO appena elencate. Ha ereditato l'ampia diffusione del linguaggio C, di cui condivide in larga misura la struttura e la funzionalità (è inoltre sempre possibile includere frammenti di C procedurale nei programmi in C++). Un oggetto in C++ viene creato a partire da una classe, che è qualcosa di analogo (ma con maggiore funzionalità) alla struct estesa prima descritta. Il C++ soffre di un grosso problema, che rende tuttora preferibile il C per la scrittura di applicazioni sufficientemente semplici: nel corso della creazione degli oggetti, come è facile intuire, vengono dinamicamente allocate in memoria le relative strutture di dati. Dal momento che è molto più difficile seguire il "flusso" di un programma OO, è piuttosto facile dimenticarsi, in fase di codifica, di liberare sempre tutta la memoria allocata. E' abbastanza tipico che i primi programmi scritti in C++ da chiunque siano letteralmente costellati di memory leak. Lo standard del C++ inoltre subisce ancora l'evoluzione di alcune delle funzionalità, il che può causare problemi di compatibilità dei compilatori. Rispetto al C, inoltre, il debugging è più complicato (come si fa a identificare le funzioni polimorfe ?).

• Java: Questo linguaggio OO è stato introdotto dalla Sun qualche anno fa, a complemento dell'omonima architettura di esecuzione di bytecode indipendente dalla piattaforma. E' unito ad una potente libreria standard per la creazione di interfacce grafiche. La struttura del linguaggio non prevede la liberazione manuale della memoria dinamica, che viene infatti liberata in modo automatico. Problemi di prestazioni in esecuzione hanno finora limitato l'espansione del suo utilizzo, che però ha fra le sue potenzialità anche applicazioni real-time.