Da Simula e Smalltalk alle classi e ai prototipi moderni: oggetti, messaggi, incapsulamento, polimorfismo e limiti dell'ereditarietà.
La programmazione orientata agli oggetti (OOP) è oggi così familiare che è facile dimenticarne l’evoluzione storica. Classi, oggetti, metodi, ereditarietà, interfacce e polimorfismo non nacquero insieme né come ricetta universale.
L’orientamento agli oggetti nasce da una domanda pratica: come rappresentare entità dotate di stato, comportamento e interazioni con altre entità? Da Simula a Smalltalk, poi C++, Java, Python e JavaScript, le risposte cambiarono profondamente.
I linguaggi di alto livello degli anni Cinquanta e Sessanta introdussero funzioni, procedure, strutture dati e moduli. Con sistemi sempre più grandi, modificare dati manipolati da funzioni sparse diventava costoso. Una delle risposte più influenti arrivò dalla simulazione.
Negli anni Sessanta gli informatici norvegesi Ole-Johan Dahl e Kristen Nygaard svilupparono linguaggi di simulazione. Con Simula 67 introdussero meccanismi fondamentali: classi, oggetti, ereditarietà e metodi virtuali. Una classe descrive una categoria; un oggetto ne rappresenta un’istanza concreta.
Nel modello classico, una classe definisce struttura e comportamenti comuni e un oggetto è un’istanza con stato proprio. Il modello è centrale in C++, Java e C#, ma non universale: esistono sistemi basati sui prototipi.
Tra la fine degli anni Sessanta e l’inizio dei Settanta, Alan Kay sviluppò un’altra visione, approfondita nella nostra biografia di Alan Kay: l’idea essenziale erano oggetti autonomi che si scambiano messaggi, non le gerarchie di classi.
Al Xerox PARC, Alan Kay, Dan Ingalls, Adele Goldberg e altri svilupparono Smalltalk. Numeri, collezioni e classi partecipano al modello a oggetti e l’interazione ruota attorno ai messaggi. L’ambiente interattivo influenzò profondamente personal computing e IDE.
Un oggetto combina normalmente stato, comportamento e identità. Due conti bancari possono avere lo stesso saldo senza essere lo stesso conto. In alcuni domini l’identità è fondamentale; in altri valori immutabili e funzioni sono più adatti. L’OOP è quindi uno strumento, non un obbligo universale.
L’incapsulamento riunisce stato e operazioni e limita l’accesso ai dettagli interni. Il suo scopo è ridurre le dipendenze e permettere a un’astrazione di cambiare senza rompere chi la utilizza.
L’astrazione mostra ciò che un componente sa fare senza esporne l’implementazione. L’OOP non ha inventato l’astrazione, ma ne ha diffuso una forma centrata su entità che combinano stato e comportamento.
L’ereditarietà permette a una classe di acquisire e specializzare caratteristiche di un’altra. Può riutilizzare codice, ma crea anche accoppiamento e gerarchie rigide. Oggi è considerata uno strumento tra molti.
Il polimorfismo permette allo stesso codice di lavorare con oggetti diversi attraverso un comportamento comune. Può basarsi su ereditarietà, interfacce, protocolli, duck typing o generics. L’idea centrale è programmare verso un contratto e non verso un’implementazione concreta.
Dal 1979 Bjarne Stroustrup combinò idee di Simula con l’efficienza di C. Il progetto divenne C++, che diffuse l’OOP nell’industria senza abbandonare altri paradigmi.
Objective-C, creato da Brad Cox e Tom Love, seguì una strada diversa: uno strato dinamico sopra C ispirato ai messaggi di Smalltalk. Divenne importante in NeXT e Apple prima di Swift.
Negli anni Novanta interfacce grafiche, design pattern e UML contribuirono alla diffusione dell’OOP. Fu talvolta presentata come un metodo generale per progettare qualunque sistema, producendo pratiche durature ma anche eccessi.
Java arrivò nel 1995 con classi, garbage collection e interfacce. La nostra storia di Java e la biografia di James Gosling approfondiscono questa evoluzione.
C# riprese poi molte idee familiari in .NET e si evolse con generics, lambda, LINQ, record e pattern matching. Anche i linguaggi fortemente associati all’OOP sono diventati multiparadigma.
Python supporta classi e polimorfismo senza imporli ovunque. Il duck typing privilegia spesso i comportamenti disponibili rispetto a una gerarchia precisa.
JavaScript, creato da Brendan Eich, si basa storicamente sui prototipi. La moderna sintassi class continua a poggiare su questo meccanismo.
Con l’esperienza si è diffuso il consiglio preferire la composizione all’ereditarietà. La composizione riduce spesso l’accoppiamento e facilita la sostituzione dei componenti. Non rende inutile l’ereditarietà, ma evita di trasformare ogni riuso in un albero di classi.
Le interfacce separano ciò di cui un componente ha bisogno dall’implementazione concreta. Questa idea è alla base della dependency injection e di diversi principi SOLID.
SOLID è un insieme di euristiche, non di leggi. Un’applicazione meccanica può moltiplicare classi, interfacce e livelli senza vantaggi. Un’astrazione è utile quando rappresenta un vero confine di responsabilità o variazione.
Nel 1994 Design Patterns rese popolari pattern come Factory, Observer, Strategy, Decorator e Adapter. Il loro valore principale è offrire un vocabolario condiviso, non ricette obbligatorie.
UML unificò diversi metodi di modellazione e i diagrammi delle classi divennero strettamente associati all’OOP. Pattern e diagrammi aiutano a ragionare, ma non sostituiscono un design adatto al problema.
Incapsulamento, interfacce e dependency injection possono facilitare i test attraverso fake, stub o mock. Ma frammentare un’architettura solo per agevolare il mocking può peggiorarla. Più astrazioni non significano automaticamente design migliore.
Con il predominio dell’OOP emersero limiti: gerarchie profonde e fragili, stato mutabile condiviso, oggetti troppo interconnessi e architetture “enterprise” sovraccariche di livelli e factory.
La programmazione funzionale ha riportato in primo piano funzioni pure e dati immutabili. Oggi Java, C#, C++, Python e JavaScript combinano approcci diversi. L’opposizione «oggetti contro funzionale» è quindi sempre meno utile.
Interfacce grafiche e giochi si prestano ancora bene a entità con stato e identità, ma i motori moderni usano anche Entity Component System (ECS) che privilegiano composizione e separazione dei dati.
Nei sistemi distribuiti, il modello ad attori organizza entità che ricevono messaggi e mantengono il proprio stato. Non è OOP classica, ma ricorda l’importanza attribuita da Alan Kay a messaggi e isolamento.
Dopo decenni, incapsulamento, polimorfismo, composizione, identità e stato restano idee particolarmente durature. La grande gerarchia di classi ha invece perso influenza.
Smalltalk, C++, Java, Python e JavaScript mostrano che l’OOP è meglio compresa come una famiglia di modelli di programmazione che come una checklist assoluta.
Una quantità enorme di software e framework usa classi e oggetti. Comprendere incapsulamento, responsabilità, contratti e polimorfismo rimane utile. La maturità consiste meno nel «mettere oggetti ovunque» che nello scegliere la rappresentazione adatta al problema.
L’OOP nasce progressivamente con Simula, cambia con Smalltalk e Alan Kay, si diffonde industrialmente con C++ e diventa dominante con Java. Python e JavaScript mostrano modelli più dinamici e multiparadigma.
L’esperienza ha corretto alcuni eccessi: l’ereditarietà non è più la risposta naturale a ogni riuso, mentre composizione, interfacce, immutabilità e funzioni hanno acquisito importanza.
La lezione più duratura non è «tutto deve essere una classe», ma raggruppare responsabilità coerenti, nascondere dettagli inutili e permettere ai componenti di collaborare senza dipendere eccessivamente dalle implementazioni interne.
È una famiglia di approcci che organizza il software attorno a oggetti con stato, identità e comportamento che collaborano tramite metodi, messaggi o interfacce.
Non esiste un unico inventore. Dahl e Nygaard introdussero meccanismi fondamentali in Simula; Alan Kay e il team Smalltalk svilupparono poi una visione centrata sui messaggi.
Una classe descrive struttura e comportamenti comuni; un oggetto è un’istanza particolare con stato proprio. I sistemi a prototipi funzionano diversamente.
Incapsulamento, astrazione, ereditarietà e polimorfismo; nella pratica moderna anche composizione, interfacce e gestione delle dipendenze.
No. Molti sistemi preferiscono composizione o interfacce.
Sì, ma storicamente tramite prototipi. Anche la sintassi class moderna si basa su di essi.
Sì, ma è multiparadigma e non obbliga a organizzare tutto in classi.
No. È ancora molto usata, ma non viene più considerata una soluzione universale.
Spesso la composizione produce componenti più flessibili e meno accoppiati. L’ereditarietà resta utile quando esiste una vera specializzazione.
Perché incapsulamento, responsabilità, contratti e polimorfismo aiutano ancora a gestire la complessità nelle architetture multiparadigma.
Raccolta
10 / 26
Come Bjarne Stroustrup ha trasformato C with Classes in C++, un linguaggio che concilia astrazione, compatibilità e controllo delle risorse.
Come Brendan Eich creò il primo JavaScript in Netscape e contribuì alla sua evoluzione nel linguaggio standardizzato del Web.
Come James Gosling e il team Green di Sun progettarono Java: da Oak alle macchine virtuali e alla promessa della portabilità.