Programmazione orientata agli oggetti (OOP)

Approfondimento

Un oggetto vive nella memoria dinamica (heap) e la variabile che lo «contiene» custodisce in realtà un riferimento (un indirizzo) ad esso: per questo assegnare «b = a» fa sì che a e b puntino allo stesso identico oggetto, non a una copia. Da qui la distinzione capitale fra identità e uguaglianza: due riferimenti sono identici se puntano allo stesso oggetto in memoria (in Python «a is b», in Java «a == b» sui riferimenti), mentre due oggetti sono uguali se hanno lo stesso stato secondo un criterio definito dalla classe (il metodo «equals» in Java, «__eq__» in Python, da ridefinire coerentemente con «hashCode»). Il ciclo di vita di un oggetto va dalla costruzione, quando il costruttore ne fissa uno stato valido, all'uso, fino alla distruzione: nei linguaggi con garbage collector (Java, Python) la memoria di un oggetto non più raggiungibile viene recuperata automaticamente, mentre in C++ va rilasciata esplicitamente da un distruttore. Accanto ai membri d'istanza esistono i membri di classe («static»), condivisi da tutte le istanze — utili per un contatore di oggetti creati o per costanti — a cui si accede tramite la classe e non tramite un singolo oggetto (per questo un metodo statico non dispone di «this»/«self»). Molti linguaggi permettono infine il sovraccarico del costruttore (più costruttori con parametri diversi), per offrire modi alternativi di creare un oggetto sempre ben inizializzato.

Approfondimento

L'incapsulamento non serve solo a «nascondere»: il suo scopo profondo è custodire un'invariante di classe, una proprietà che deve valere per tutta la vita dell'oggetto (per esempio «saldo ≥ 0» in un conto, «0 ≤ ora < 24» in un orario). Rendendo privati gli attributi e incanalando ogni modifica attraverso metodi che verificano l'invariante, si garantisce che l'oggetto non possa mai trovarsi in uno stato incoerente: è l'esatto analogo, per i dati, dell'invariante di ciclo per gli algoritmi. L'idea è formalizzata da D. Parnas (1972): un modulo deve nascondere le decisioni progettuali soggette a cambiamento, esponendo solo un'interfaccia stabile. Una forma forte di incapsulamento è l'immutabilità: un oggetto i cui campi, una volta costruiti, non cambiano più (attributi «final» in Java, oggetti «read-only») non può violare le proprie invarianti né essere corrotto da accessi concorrenti, e per questo è più sicuro da condividere fra più parti del programma. Sul piano progettuale, l'incapsulamento riduce l'accoppiamento (coupling) fra le classi e ne aumenta la coesione (cohesion): meno una classe conosce dei dettagli interni delle altre — principio riassunto dalla «legge di Demeter», «parla solo con i tuoi amici diretti» — più il sistema si può modificare senza propagare effetti a catena. È questo disaccoppiamento, non il semplice divieto di accesso, il vero guadagno dell'information hiding.

Approfondimento

L'ereditarietà multipla, ammessa in C++ e Python, apre il celebre problema del diamante: se «D» eredita da «B» e «C», che a loro volta ereditano entrambe da «A», e sia «B» sia «C» ridefiniscono uno stesso metodo, quale versione eredita «D»? Per sciogliere l'ambiguità Python fissa un ordine di risoluzione dei metodi (MRO, linearizzazione C3) che stabilisce univocamente la catena di ricerca; Java elude il problema alla radice, ammettendo l'ereditarietà singola fra classi e concedendo solo l'implementazione di più interfacce. Un difetto insidioso delle gerarchie profonde è la classe base fragile (fragile base class): una modifica apparentemente innocua alla superclasse può rompere silenziosamente le sottoclassi che ne dipendevano. È il motivo tecnico della linea guida «preferire la composizione all'ereditarietà»: invece di far ereditare «Automobile» da «Motore» (che non è affatto una relazione «è-un»), si dà ad «Automobile» un attributo di tipo «Motore» (relazione «ha-un»), ottenendo lo stesso riuso con minore accoppiamento e maggiore flessibilità — si può perfino sostituire il motore a tempo di esecuzione. Il criterio ultimo di una gerarchia corretta è che ogni sottoclasse sia realmente sostituibile alla superclasse senza sorprese per chi la usa, principio che il polimorfismo formalizza nella sezione seguente e che distingue una gerarchia «è-un» solo di nome da una davvero ben progettata.

Approfondimento

Il polimorfismo dinamico ha un'implementazione concreta ed elegante: a ogni classe con metodi ridefinibili il compilatore associa una tabella dei metodi virtuali (vtable), un vettore di puntatori alle versioni effettive dei metodi; ogni oggetto porta con sé un riferimento alla vtable della propria classe, così la chiamata «figura.area()» diventa una consultazione della tabella a tempo di esecuzione (dynamic dispatch) e finisce nella versione giusta. Perché il polimorfismo sia corretto, però, non basta la meccanica: deve valere il principio di sostituzione di Liskov (LSP), secondo cui un oggetto di una sottoclasse deve poter sostituire uno della superclasse senza alterare la correttezza del programma — la sottoclasse non deve rafforzare le precondizioni né indebolire le postcondizioni dei metodi ereditati. Il controesempio classico è «Quadrato» che eredita da «Rettangolo»: se un rettangolo permette di fissare larghezza e altezza in modo indipendente, un quadrato che le tiene forzatamente uguali viola le aspettative di chi lo tratta come rettangolo, e la gerarchia — pur «è-un» in geometria — risulta scorretta nel software. Sul piano progettuale il polimorfismo è il motore di molti schemi ricorrenti (design pattern): nel pattern Strategy, per esempio, un algoritmo intercambiabile viene incapsulato in oggetti che implementano una stessa interfaccia e vengono scelti a run-time — la stessa idea che realizza il principio «aperto all'estensione, chiuso alla modifica».

Approfondimento

Il diagramma delle classi coglie la struttura statica del sistema, ma un progetto completo descrive anche il comportamento dinamico con altri diagrammi UML: il diagramma dei casi d'uso (use case) fissa che cosa gli attori possono fare con il sistema; il diagramma di sequenza mostra lo scambio di messaggi fra oggetti nel tempo per realizzare un'operazione (chi chiama chi, e in quale ordine); il diagramma di stato descrive come un oggetto cambia stato in risposta agli eventi (un «Prestito» passa da «attivo» a «scaduto» a «restituito»). Struttura e comportamento sono le due facce complementari del modello. Per giudicare la qualità di un progetto si usano due criteri: alta coesione (ogni classe ha una responsabilità ben definita) e basso accoppiamento (le classi dipendono le une dalle altre il meno possibile). Questi criteri si sistematizzano nei principi SOLID — fra cui la singola responsabilità (una classe, un solo motivo per cambiare) e l'inversione delle dipendenze (dipendere da astrazioni, non da implementazioni concrete). Le soluzioni ricorrenti a problemi di progettazione noti sono infine catalogate come design pattern (schemi della «Gang of Four»), classificati in creazionali (come si creano gli oggetti, p. es. Factory), strutturali (come si compongono, p. es. Adapter) e comportamentali (come collaborano, p. es. Observer, Strategy): conoscerli significa riusare non solo codice, ma esperienza di progettazione consolidata.