Los límites de POP: cuándo un enum o una clase son mejores

Cuatro lecciones defendiendo los protocolos piden una quinta que marque el límite. La programación orientada a protocolos resuelve un problema real —compartir comportamiento sin acoplar jerarquías— y como toda buena idea se aplica en exceso: protocolos con un solo conformante, envoltorios de borrado de tipos escritos a mano, restricciones genéricas que se propagan por media base de código. Hay dos herramientas que Swift ofrece con el mismo rango y que a menudo son la respuesta correcta: el enum, cuando el conjunto de casos es cerrado, y la class, cuando lo que modelas tiene identidad. Saber cuándo abandonar el protocolo es tan técnico como saber escribirlo.

Señales de contorsión

Ninguna de estas señales condena un diseño por sí sola; tres juntas casi siempre sí.

Hay un caso especialmente frecuente: el protocolo creado solo para poder inyectar un doble en los tests. A veces está justificado; a menudo la misma independencia se consigue inyectando una función, una struct con closures o un valor de configuración, sin añadir un tipo abstracto permanente al dominio.

// Version 1. Contorsion: protocolo de un solo conformante mas su doble de test.
protocol ServicioUsuario {
    func cargar(id: String) async throws -> Usuario
}

// Version 2. La dependencia es una funcion, y el doble es otra funcion.
struct ServicioUsuario {
    var cargar: (String) async throws -> Usuario
}

extension ServicioUsuario {
    static let real = ServicioUsuario { id in try await red.get(id) }
    static let prueba = ServicioUsuario { _ in Usuario.ejemplo }
}

La segunda versión no declara ningún tipo abstracto, no obliga a mantener dos firmas sincronizadas y permite construir un doble parcial en una línea dentro del propio test. La abstracción sigue existiendo; simplemente ha dejado de necesitar un protocol para expresarse.

Cuando gana el enum: el conjunto cerrado

Si las variantes son conocidas y finitas, el enum domina al protocolo en todos los ejes que importan.

enum Pago {
    case efectivo(Decimal)
    case tarjeta(numero: String, cuota: Int)
    case transferencia(iban: String)
}

func comision(de pago: Pago) -> Decimal {
    switch pago {
    case .efectivo: return 0
    case .tarjeta(_, let cuota): return cuota > 1 ? 3 : 1
    case .transferencia: return Decimal(0.5)
    }
}

Las ventajas son concretas, no estéticas. El switch es exhaustivo: añadir un caso rompe la compilación en cada punto que deba actualizarse, lo cual es exactamente lo que quieres. No hay caja ni indirección: el valor cabe en la pila. Los datos asociados difieren por caso sin necesidad de propiedades opcionales que solo tienen sentido a veces. Y añadir una operación nueva es escribir una función nueva, sin tocar ninguna declaración existente.

Con protocolos, ese mismo modelo pierde la exhaustividad —nada avisa de que falta manejar un conformante— y gana una libertad, la de que terceros añadan tipos, que en un dominio cerrado como los medios de pago no sirve para nada.

Cuando gana la clase: identidad y estado compartido

Los tipos por valor se copian, y hay cosas que no deben copiarse. Una conexión abierta, un caché compartido, un coordinador de navegación, un objeto que otros observan: todos ellos tienen identidad, y esa identidad es el modelo, no un detalle de implementación.

final class Sesion {
    private(set) var token: String?
    private var observadores: [() -> Void] = []

    func renovar(_ nuevo: String) {
        token = nuevo
        observadores.forEach { $0() }
    }

    deinit { /* cerrar recursos */ }
}

La clase aporta cuatro cosas que ningún protocolo sobre un tipo por valor da: una referencia compartida donde todos ven la misma mutación, deinit para liberar recursos de forma determinista, referencias weak para romper ciclos, y comparación por identidad. Si tu diseño acaba pasando el mismo struct con inout por veinte funciones para que todas vean el cambio, estás reimplementando una clase peor.

Cuando además hay concurrencia, la respuesta suele ser un actor: identidad más aislamiento de estado, sin candados manuales.

flowchart TB
q1{el conjunto de variantes es cerrado} -->|si| en[enum con switch exhaustivo]
q1 -->|no| q2{importa la identidad o el estado compartido}
q2 -->|si y hay concurrencia| ac[actor]
q2 -->|si| cl[class final]
q2 -->|no| q3{habra varios conformantes reales}
q3 -->|no| st[una struct concreta basta]
q3 -->|si| pr[protocolo con extensiones]

El criterio de fondo