Modelar el dominio con enums: estados inválidos irrepresentables

Un enum con datos no es una comodidad sintáctica: es una técnica de diseño. Cuando cada estado de tu sistema lleva exactamente los datos que ese estado necesita, y ningún otro, los estados imposibles dejan de poder escribirse. El bug no se detecta antes: sencillamente no cabe en el tipo. Este es el salto de “usar enums” a “diseñar con enums”, y es una de las ideas más poderosas que Rust toma de la programación funcional.

El pecado del struct con campos opcionales

Mira cómo se modela típicamente una conexión de red en un lenguaje sin tipos suma ricos: un struct con un campo de estado y un montón de campos que a veces aplican:

// El anti-patrón: campos que solo valen en ciertos estados
struct Conexion {
    estado: String,              // "conectando" | "conectada" | "cerrada"
    socket: Option<Socket>,      // solo si conectada... ¿o conectando?
    desde: Option<Instant>,      // solo si conectada
    motivo_cierre: Option<String>, // solo si cerrada
}

Este tipo permite escribir tonterías: una conexión "cerrada" con un socket presente, una "conectada" sin desde, un motivo_cierre en una conexión que sigue viva. Cada combinación ilegal es un bug esperando su turno, y para evitarlos te llenas el código de comprobaciones defensivas y unwrap que rezan. El tipo miente: dice que hay 2⁴ combinaciones cuando el dominio real solo tiene tres estados.

La máquina de estados como enum

Un enum dice la verdad. Cada variante es un estado, y lleva solo los datos que ese estado posee. Los demás ni siquiera existen:

struct Socket;
use std::time::Instant;

enum Conexion {
    Conectando { intento: u8 },
    Conectada { socket: Socket, desde: Instant },
    Cerrada { motivo: String },
}

impl Conexion {
    // una transicion consume el estado y devuelve el siguiente
    fn confirmar(self, socket: Socket) -> Conexion {
        match self {
            Conexion::Conectando { .. } => Conexion::Conectada { socket, desde: Instant::now() },
            // desde cualquier otro estado, confirmar no tiene sentido: no transita
            otro => otro,
        }
    }
}

Ahora una Conectada siempre tiene socket y marca de tiempo; una Cerrada siempre tiene motivo y nunca socket. No hay Option, no hay defensivas: la ausencia de un campo en un estado se expresa por su ausencia en la variante. Y al hacer que las transiciones consuman self (lo mueven) y devuelvan el nuevo estado, el sistema de ownership garantiza que el estado viejo se destruye: es imposible seguir usando una Conexion que ya transitó.

stateDiagram-v2
[*] --> Conectando
Conectando --> Conectada: confirmar con socket
Conectando --> Cerrada: fallo o timeout
Conectada --> Cerrada: cerrar
Cerrada --> [*]

El AST: un enum que se recorre solo

El caso donde los tipos suma brillan más es el árbol de sintaxis abstracta. Una expresión aritmética es recursivamente “o un número, o una suma de dos expresiones, o un producto, o una negación”. Eso se traduce a un enum casi palabra por palabra:

enum Expr {
    Num(f64),
    Suma(Box<Expr>, Box<Expr>),
    Prod(Box<Expr>, Box<Expr>),
    Neg(Box<Expr>),
}

fn eval(e: &Expr) -> f64 {
    match e {
        Expr::Num(n) => *n,
        Expr::Suma(a, b) => eval(a) + eval(b),
        Expr::Prod(a, b) => eval(a) * eval(b),
        Expr::Neg(x) => -eval(x),
    }
}

fn main() {
    // representa  -(2 + 3) * 4
    let e = Expr::Prod(
        Box::new(Expr::Neg(Box::new(Expr::Suma(
            Box::new(Expr::Num(2.0)),
            Box::new(Expr::Num(3.0)),
        )))),
        Box::new(Expr::Num(4.0)),
    );
    assert_eq!(eval(&e), -20.0);
}

El Box es obligatorio: sin él, Expr se contendría a sí mismo y tendría tamaño infinito; Box mete la subexpresión en el heap y deja en el nodo solo un puntero de tamaño fijo. Fíjate en la estructura del eval: la recursión del tipo y la recursión de la función son la misma forma. El match exhaustivo garantiza que ningún tipo de nodo queda sin evaluar, y si mañana añades Expr::Div, el compilador te enviará directo a eval y a cualquier otro recorrido (un imprime, un deriva, un optimiza) a completar el caso. Un intérprete, un compilador, un motor de plantillas, un validador de reglas: todos son, en su núcleo, un enum recursivo y un puñado de match que lo recorren.

Del enum al typestate: estados que son tipos

El enum hace irrepresentables los estados incoherentes, pero por sí solo no impide llamar a un método en el estado equivocado. El siguiente peldaño codifica el estado en el tipo, no en una variante, usando un parámetro de tipo fantasma que no ocupa memoria:

use std::marker::PhantomData;

struct Abierta;
struct Cerrada;

struct Puerta<Estado> {
    _estado: PhantomData<Estado>,
}

impl Puerta<Cerrada> {
    fn abrir(self) -> Puerta<Abierta> { Puerta { _estado: PhantomData } }
}

impl Puerta<Abierta> {
    fn cerrar(self) -> Puerta<Cerrada> { Puerta { _estado: PhantomData } }
}

Ahora cerrar solo existe sobre una Puerta<Abierta>: intentar cerrar una puerta ya cerrada no es un error en ejecución, es código que no compila, porque el método ni siquiera está disponible en ese tipo. Donde el enum volvía irrepresentables los estados incoherentes, el typestate vuelve irrepresentables las transiciones ilegales. Son la misma filosofía —empujar el error al sistema de tipos— aplicada a dos ejes: el enum es el fundamento accesible que usarás el 90% de las veces; el typestate, el bisturí para las máquinas cuyo orden de operaciones debe garantizarse en compilación.