OOP: cos'è la programmazione orientata agli oggetti

Immagina di dover scrivere un programma che gestisce una scuola: studenti, corsi, voti. Puoi tenere tutto in liste di numeri e testi separati, oppure puoi raggruppare, per ogni studente, i suoi dati insieme alle azioni che lo riguardano: iscriversi a un corso, ricevere un voto. La seconda strada è quella della programmazione orientata agli oggetti, la OOP: uno stile di programmazione che organizza il codice attorno a oggetti, unità che tengono insieme dati e funzioni invece di separarli. È un modo di pensare diffuso in molti linguaggi diversi, come JavaScript, TypeScript, Java, Python e C++, anche se non è l’unico possibile.

Un oggetto è dati più comportamento

Nella documentazione ufficiale del linguaggio Java, un oggetto software conserva il proprio stato in campi (le variabili che gli appartengono) ed espone il proprio comportamento attraverso metodi, cioè funzioni che operano su quello stato. I metodi sono anche il modo in cui un oggetto comunica con un altro: quando due oggetti collaborano, di solito lo fanno chiamandosi a vicenda i metodi, non leggendosi i dati direttamente.

Questa idea non è lontana da come si descrivono gli oggetti del mondo reale: una bicicletta ha uno stato (la marcia inserita in un dato momento, la velocità) e un comportamento (frenare, cambiare marcia). Tradurre questa stessa struttura nel codice è il punto di partenza della OOP.

La classe è il progetto, l’oggetto è il pezzo costruito

Un oggetto non nasce dal nulla: nasce da una classe, che la documentazione Java descrive come il progetto da cui si creano i singoli oggetti. La classe stabilisce quali campi e quali metodi avrà ogni oggetto costruito a partire da essa; l’oggetto stesso, una volta creato, si dice un’istanza di quella classe.

Esempio pratico: pensa a una classe Bicicletta. Definisce che ogni bicicletta ha uno stato (la marcia attuale) e un comportamento (cambiare marcia). Ogni singola bicicletta costruita a partire da quel progetto, con la sua marcia impostata in un dato momento, è un’istanza della classe Bicicletta: stesso progetto, oggetti diversi.

Incapsulamento: nascondere lo stato, non il codice

Il primo dei concetti che la documentazione Java associa alla OOP è l’incapsulamento: nascondere lo stato interno di un oggetto e richiedere che ogni interazione con esso passi dai suoi metodi. Non è, come si crede spesso, una forma di segretezza sul codice sorgente: è un modo di tenere separato ciò che un oggetto fa da come lo fa internamente, così che il resto del programma possa usarlo senza doversi occupare dei suoi dettagli interni. Anche la documentazione MDN dà una definizione simile: tenere privato lo stato interno di un oggetto, con una netta divisione tra la sua interfaccia pubblica e i suoi dati privati, si chiama incapsulamento.

Ereditarietà: riusare senza riscrivere

La OOP permette a una classe di ereditare stato e comportamento comuni da un’altra classe. Nell’esempio della documentazione Java, una classe MountainBike può ereditare tutti i campi e i metodi di una classe Bicycle più generale, concentrando il proprio codice solo su ciò che la rende diversa, come le sospensioni. Il risultato, secondo la stessa fonte, è codice più facile da leggere: non bisogna ripetere in MountainBike quello che è già scritto in Bicycle.

Anche la documentazione ufficiale di Python conferma che l’ereditarietà è una funzionalità standard della OOP, con un meccanismo proprio: una classe derivata può sostituire (override) qualunque metodo della classe base, e un metodo di quest’ultima può finire per richiamare, senza saperlo, la versione ridefinita nella sottoclasse.

Polimorfismo: lo stesso nome, comportamenti diversi

Quando un metodo ha lo stesso nome ma un’implementazione diversa in classi diverse, la documentazione MDN chiama questa caratteristica polimorfismo. Capita tipicamente quando una sottoclasse sostituisce (override) l’implementazione ereditata da una classe superiore, per esempio quando una MountainBike gestisce il cambio marcia in modo diverso da una Bicycle generica pur chiamandosi allo stesso modo.

Va detto con chiarezza: la documentazione MDN organizza l’intero argomento intorno a tre concetti principali, classi e istanze, ereditarietà, incapsulamento, e presenta il polimorfismo come un effetto dell’ereditarietà più che come un pilastro separato. È una delle ragioni per cui, più avanti in questo Recap, si dice che non tutte le fonti tecniche raccontano la OOP con lo stesso identico elenco di concetti.

Astrazione: definire il cosa, lasciare il come ai sottotipi

La documentazione Java descrive anche le classi astratte: una classe dichiarata astratta non può essere trasformata direttamente in un oggetto, ma può avere sottoclassi. Può contenere metodi astratti, dichiarati senza un’implementazione: sono un obbligo, non un suggerimento, perché ogni sottoclasse concreta dovrà fornirne una propria.

L’esempio della stessa fonte è una classe astratta GraphicObject: tutti gli oggetti grafici devono potersi disegnare e ridimensionare, ma ciascun tipo lo fa a modo suo, un cerchio in un modo, un rettangolo in un altro. La classe astratta cattura ciò che hanno in comune, il cosa, e lascia a ogni sottoclasse il compito di stabilire il come. Questo modo di separare l’interfaccia comune dai dettagli di attuazione è quello che le fonti chiamano astrazione.

Un’idea nata per simulare il mondo, non per scriverlo

Le radici della OOP, secondo la targa storica dell’IEEE Engineering and Technology History Wiki, risalgono al 1961, quando Ole-Johan Dahl e Kristen Nygaard cominciarono a lavorare insieme al Norwegian Computer Center a un linguaggio per descrivere simulazioni al computer. Il risultato del loro lavoro, Simula 67, fu completato nel 1967 e introdusse insieme incapsulamento, ereditarietà, il legame tardivo dei metodi e la creazione dinamica di oggetti: gli elementi che oggi si considerano essenziali in un linguaggio orientato agli oggetti. Curiosamente, l’idea di “oggetto” non nacque per scrivere software in generale, ma per modellare sistemi complessi, come le code di attesa o il traffico.

A distanza di oltre trent’anni da quel lavoro, Dahl e Nygaard ricevettero il premio Turing, il riconoscimento più importante dell’informatica, spesso paragonato al Nobel del settore, proprio per le idee alla base di Simula I e Simula 67.

Quattro pilastri? Le fonti non sono tutte d’accordo

Nella scuola e nei manuali capita spesso di leggere che la OOP si regge su quattro pilastri: incapsulamento, ereditarietà, polimorfismo e astrazione. È una sistemazione didattica utile, ma non un canone su cui tutte le fonti tecniche concordano nello stesso modo: la documentazione MDN, come si è visto, ne descrive tre e tratta il polimorfismo come una conseguenza dell’ereditarietà; altre fonti, come quella Java sulle classi astratte, trattano l’astrazione in una pagina a parte, senza inserirla in un elenco numerato di pilastri. Conoscere questa sfumatura aiuta a non presentare come un dato fisso quello che, in realtà, è un modo tra i possibili di organizzare lo stesso insieme di idee.

Questi concetti non appartengono a un solo linguaggio. La storia del computer mostra come i linguaggi di programmazione si siano evoluti in stili diversi nel tempo; oggi la OOP convive con altri approcci, e il modo in cui un programma la applica dipende anche da cosa deve fare, per esempio elaborare dati destinati a un database relazionale o eseguire un algoritmo di calcolo. La documentazione ufficiale di Python conferma che gli stessi concetti, ereditarietà multipla compresa, si ritrovano anche in un linguaggio con una sintassi molto diversa da quella di Java.