Al desarrollar con Swift, hay un momento que a todos nos hace dudar.
«¿Lo hago con class o con struct?»
Cuando aprendí Swift, elegía entre ambos según me apetecía. Solo estudié bien la diferencia después de sufrir un bug extraño.
Voy directo a la conclusión.
Si no hay un motivo especial, elige primero una estructura (struct).
Usa una clase solo cuando necesites un «estado compartido».
La guía oficial de Apple sostiene lo mismo. Hoy explicaré el motivo paso a paso.
Resumen clave (3 puntos)
Para quienes tienen prisa, aquí va el resumen.
- Una estructura es un tipo por valor. Al copiarla, se convierte en un valor completamente distinto.
- Una clase es un tipo por referencia. Aunque la copies, ambas referencias apuntan a la misma instancia.
- Si dudas, usa struct primero; reserva class para cuando necesites herencia o estado compartido.
Con recordar estas tres líneas ya tienes la mitad hecha.
¿Qué diferencia hay entre un tipo por valor y uno por referencia?
Dicho así puede resultar confuso. Lo más rápido es verlo en código.
Primero, las estructuras. En cuanto las copias, dejan de tener relación.
struct Point { var x = 0 }
var a = Point()
var b = a // Valor copiado
b.x = 10
print(a.x, b.x)
// Salida: 0 10Aunque cambies b, a permanece igual. Cada uno tiene su propio valor.
Ahora, las clases. El código parece el mismo, pero el resultado cambia.
class Box { var x = 0 }
let a = Box()
let b = a // Referencia copiada (mismo objeto)
b.x = 10
print(a.x, b.x)
// Salida: 10 10Solo cambié b, pero a también pasó a ser 10.
Es porque ambas apuntan a la misma instancia. Ese era exactamente el bug que me atormentaba.
Entonces, ¿cuándo usar cada uno? (Criterios)
Para decidir en proyectos reales, visualizo esta tabla.
| Situación | Decisión |
|---|---|
| Modelo que solo contiene datos | Estructura |
| Se busca que las copias sean independientes | Estructura |
| La herencia es imprescindible | Clase |
| Se comparte la misma instancia en varios lugares | Clase |
| Hay que interoperar con Objective-C | Clase |
En más detalle, el criterio es el siguiente.
- Para representar el valor en sí, como coordenadas, colores o tamaños, una estructura resulta natural.
- Si varios lugares deben observar un mismo estado compartido, como en un controlador de pantalla o un gestor de red, conviene una clase.
- Que SwiftUI de Apple defina View como struct responde al mismo motivo: es ligero y predecible.
Por cierto, Array, String y Dictionary de la biblioteca estándar de Swift son estructuras. Es otra señal de que el tipo por valor es la opción predeterminada.
Por qué recomiendo empezar con estructuras
Los tipos por valor son fáciles de predecir.
No tienes que preocuparte de que el valor que pasaste cambie a escondidas en otro lugar. Aunque lo pases a una función, el original está a salvo.
También dan tranquilidad en entornos multihilo. Como no hay estado compartido, disminuyen las carreras de datos.
Las clases, en cambio, son potentes pero exigen cuidado. Si varios sitios retienen la misma instancia, resulta difícil rastrear dónde cambia el valor.
Por eso, adoptar «struct por defecto, class solo cuando haga falta» reduce mucho los bugs.
Cuándo usar cada uno y cuándo evitarlos
Por último, he condensado los criterios.
- Usa estructuras: modelos centrados en datos, copias independientes o cuando la seguridad entre hilos sea importante.
- Usa clases: cuando necesites herencia, compartir una instancia o cuando la identidad tenga significado.
- Evita: usar class por costumbre en modelos simples o forzar una solución alternativa con struct cuando necesitas compartir.
Así te lo preguntan en una entrevista
P. ¿Cuál es la mayor diferencia entre una estructura y una clase?
Una estructura es un tipo por valor y una clase, un tipo por referencia. Al copiar una estructura obtienes un valor completamente independiente; al copiar una clase, ambas referencias apuntan a la misma instancia. Además, solo las clases admiten herencia y pueden tener un destructor (deinit).
P. ¿Por qué Swift recomienda usar estructuras?
Porque los tipos por valor no tienen estado compartido, por lo que generan menos efectos secundarios y son más predecibles. El original no cambia accidentalmente y son seguros en entornos multihilo, lo que ayuda a reducir bugs.
Al principio también creía que solo era una diferencia de sintaxis, pero cuanto más profundizaba, más claro veía que era una cuestión de diseño.
Si asimilas estos criterios, desde tu próximo proyecto dudarás menos. Valor o estado compartido: empieza siempre por esa pregunta.