Nel corso dei precedenti capitoli ho più volte detto che le classi servono per creare nuovi tipi e aggiungere a questi nuove funzionalità, così da estendere le normali capacità del Framework, ma ho detto la stessa cosa delle strutture, magari enfatizzandone di meno l'importanza. Le classi possono esporre campi, e le strutture anche; le classi possono esporre proprietà, e le stutture anche; le classi possono esporre metodi, e le strutture anche; le classi possono esporre costruttori, e le strutture anche; le classi e i membri di classe possono avere specificatori di accesso, e le strutture e i loro membri anche. Insomma... a dirla tutta sembrerebbe che classi e strutture siano concetti un po' ridondanti, creati solo per avere un tipo reference e un tipo value, ma in definitiva molto simili.
Ovviamente non avrei scritto questo capitolo se le cose fossero state realmente così. Le classi sono infinitamente più potenti delle strutture e fra pochissimo capirete il perchè.

Memorizzazione

Iniziamo col chiarire un aspetto già noto. Le strutture sono tipi value, mentre le classi sono tipi reference. Ripetendo concetti già spiegati precedentemente, le prime vengono collocate direttamente sullo stack, ossia sulla memoria principale, nello spazio riservato alle variabili del programma, mentre le seconde vengono collocate in un'altra parte della memoria (heap managed) e pongono sullo stack solo un puntatore alla loro vera locazione. Questo significa principalmente due cose:

• L'accesso a una struttura e ai suoi membri è più rapido di un accesso ad una classe;
• La classe occupa più memoria, a parità di membri (almeno 6 bytes in più).

Inoltre, una struttura si presta meglio alla memorizzazione "lineare", ed è infatti grandemente preferita quando si esegue il marshalling dei dati (ossia la loro trasformazione da entità alla pura rappresentazione in memoria, costituita da una semplice serie di bits). In questo modo, per prima cosa è molto più facile leggere e scrivere strutture in memoria se si devono attuare operazioni di basso livello, ed è anche possibile risparmiare spazio usando un'opportuna disposizione delle variabili. Le classi, al contrario, non sono così ordinate, ed è meno facile manipolarle. Non mi addentrerò oltre in questo ambito, ma, per chi volesse, ci sono delle mie dispense che spiegano come funziona la memorizzazione delle strutture.

Identità

Un'altra conseguenza del fatto che le classi siano tipi reference consiste in questo: due oggetti, a parità di campi, sono sempre diversi, poiché si tratta di due istanze distinte, seppur contenti gli stessi dati. Due variabili di tipo strutturato che contengono gli stessi dati, invece, sono uguali, perchè non esiste il concetto di istanza per i tipi value. I tipi value sono, per l'appunto, valori, ossia semplici dati, informazione pura, ammasso di bits, né più né meno. Per questo motivo, ad esempio, è impossibile modificare una proprietà di una struttura tramite l'operatore punto, poiché sarebbe come tentare di modificare la parte decimale di 1.23: 1.23 è sempre 1.23, si tratta di un valore e non lo si può modificare, ma al massimo si può assegnare un altro valore alla variabile che lo contiene.
Al contrario, gli oggetti sono entità più complesse: non si tratta di "informazione pura" come i tipi strutturati. Un oggetto contiene molteplici campi e proprietà sempre modificabili, perchè indicano solo un aspetto dell'oggetto: ad esempio, il colore di una parete è sempre modificabile: basta tinteggiare la parete con un nuovo colore. Come dire che "la parete" non è come un numero, che è sempre quello e basta: essa è un qualcosa di concreto con diverse proprietà.
Sono concetti molto astratti e per certi versi molto ardui da capire di primo acchito... io ho tentato di fare esempi convinceti, ma spero che con il tempo imparerete da soli a interiorizzare queste differenze - differenze che, pur essendo importanti, non sono le più importanti.

Paradigma di programmazione ad oggetti

Ed eccoci arrivati al punto caldo della discussione. La sostanziale differenza che separa nettamente strutture da classi è l'aderenza ai dettami del paradigma di programmazione ad oggetti, in particolare ad ereditarietà e polimorfismo. Le classi possono ereditare certi membri da altre classi e modificarne il funzionamento. Le strutture non possono fare questo. Inoltre, le classi possono implementare interfacce, ossia sistemare i propri membri per aderire a scheletri di base: le strutture non permettono di fare neppure questo.
Queste tre carateristiche (ma le prime due in particolare) sono potenti strumenti a disposizione del programmatore, e nei prossimi capitoli le analizzeremo nel dettaglio.