Risposta.

Storia della domanda

In Swift fin dall'inizio si è posto l'accento sui value types — le strutture (struct) come strumento principale per la modellazione dei dati. A differenza di Objective-C, dove tutto era oggetti (classi), Swift incoraggia l'uso delle strutture per modelli semplici, dati e piccoli oggetti business.

Problema

Molti sviluppatori, soprattutto quelli con esperienza in altri linguaggi orientati agli oggetti, usano erroneamente le classi per tutto. Questo porta a problemi di memoria (riferimento cicli), cambiamenti inattesi durante la trasmissione degli oggetti e difficoltà con la thread safety, poiché le classi sono reference types.

Soluzione

Le strutture in Swift sono value types, vengono copiate durante l'assegnazione e la trasmissione in funzioni, a differenza delle classi (reference types), che passano solo un riferimento. Questo rende le strutture preferibili per modelli senza logiche di vita complesse e senza ereditarietà.

Esempio di codice:

struct Point {
    var x: Int
    var y: Int
}

var p1 = Point(x: 10, y: 20)
var p2 = p1
p2.x = 30
// p1.x rimane uguale a 10

Caratteristiche chiave:

La copia di una struttura provoca sempre una copia dei valori (value semantics)
Meno possibilità di perdita di memoria
Non supportano l'ereditarietà, solo protocolli

Domande trabocchetto.

Una struttura può avere un erede (subclass)?

No, le strutture in Swift non supportano l'ereditarietà. Qualsiasi estensione del comportamento è possibile solo attraverso protocolli ed estensioni.

Significa che la struttura viene sempre copiata durante la trasmissione in funzione?

Nella pratica, Swift utilizza ottimizzazioni Copy-On-Write. Se non modifichiamo la struttura, non viene copiata, e la copia viene creata solo al momento della modifica. Questo vale per le collezioni standard e le strutture complesse.

var arr1 = [1, 2, 3]
var arr2 = arr1
arr2.append(4) // Solo qui avviene la copia

In quali casi non si può utilizzare una struttura?

Se è richiesta l'identità (oggettualità, confronto tramite riferimento)
Se è necessaria un'eredità
Se deve esserci un'unica istanza (singleton)

Errori tipici e anti-pattern

Uso di classi per modelli semplici e strutture dati
Memorizzazione di tipi reference all'interno di strutture e tentativi di copiarli
Aspettativa di passare una struttura "per riferimento" e tentativi di modificare un oggetto esterno tramite struttura

Esempio della vita reale

Caso negativo

Utilizzo di classi per memorizzare dati omogenei (ad esempio, per punti su una mappa), come risultato — perdite di prestazioni dovute a frequenti accessi alla memoria, gestione complessa della memoria e bug con riferimenti invertiti.

Vantaggi:

Possibilità di memorizzare in un array come AnyObject

Svantaggi:

Minore prestazione
Difficoltà con la thread safety
Problemi con la gestione della memoria

Caso positivo

Utilizzo di strutture per modelli di dati che vengono copiati in modo sicuro, che non portano a perdite e non hanno complessità inutili.