Qué genera exactamente una data class

Escribir data delante de class es probablemente el gesto con mejor relación entre pulsaciones y código generado de todo Kotlin: cinco caracteres a cambio de cinco familias de miembros que tendrías que escribir, revisar y mantener a mano. Pero esa economía tiene letra pequeña. El compilador no genera lo que tú querías decir: genera exactamente lo que dicta una regla mecánica sobre el constructor primario, y todo lo que quede fuera de esa regla queda fuera del contrato para siempre. Entender la regla, y no el eslogan, es la diferencia entre usar una data class y confiar en ella.

Los cinco miembros generados

Partamos de la declaración más sosa posible y hagamos el ejercicio de escribir a mano lo que el compilador escribe por nosotros. Toda la magia de una data class cabe en una expansión mecánica que puedes reproducir de memoria:

data class Usuario(val id: Long, val nombre: String, val email: String)

El compilador, al ver data, sintetiza esto sobre las propiedades del constructor primario:

class Usuario(val id: Long, val nombre: String, val email: String) {

    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is Usuario) return false
        return id == other.id && nombre == other.nombre && email == other.email
    }

    override fun hashCode(): Int {
        var result = id.hashCode()
        result = 31 * result + nombre.hashCode()
        result = 31 * result + email.hashCode()
        return result
    }

    override fun toString(): String =
        "Usuario(id=$id, nombre=$nombre, email=$email)"

    fun copy(
        id: Long = this.id,
        nombre: String = this.nombre,
        email: String = this.email,
    ): Usuario = Usuario(id, nombre, email)

    operator fun component1(): Long = id
    operator fun component2(): String = nombre
    operator fun component3(): String = email
}

Cinco detalles de esa expansión merecen atención. Primero, equals empieza por una comprobación de identidad this === other que actúa como atajo barato antes de comparar campo a campo. Segundo, el descarte usa other !is Usuario, no una comparación de clases exacta; como las data class son finales, ambas cosas coinciden. Tercero, hashCode acumula con el factor 31, el mismo primo impar que usa la convención de la JVM porque el compilador puede convertir esa multiplicación en un desplazamiento y una resta. Cuarto, copy no es un método especial del lenguaje sino una función normal con valores por defecto: en el backend de la JVM eso implica un método sintético adicional, habitualmente llamado copy$default, que recibe una máscara de bits indicando qué argumentos fueron omitidos. Y quinto, las funciones componentN llevan el modificador operator, que es precisamente lo que las conecta con el desestructurado.

El constructor primario es la frontera

La regla que gobierna todo lo anterior se enuncia en una línea: solo participan las propiedades declaradas en el constructor primario. Nada de lo que declares en el cuerpo de la clase entra en equals, ni en hashCode, ni en toString, ni en copy, ni recibe una función componentN.

flowchart TD
A[data class Punto] --> B[Constructor primario val x val y]
A --> C[Cuerpo de la clase var etiqueta]
B --> D[equals y hashCode]
B --> E[toString]
B --> F[copy con valores por defecto]
B --> G[component1 y component2]
C -.-> H[No participa en ningun miembro generado]

El efecto práctico es más agresivo de lo que suele esperarse:

data class Punto(val x: Int, val y: Int) {
    var etiqueta: String = "sin etiqueta"
}

val a = Punto(1, 2).apply { etiqueta = "origen" }
val b = Punto(1, 2)

println(a == b)         // true: etiqueta no participa en equals
println(a.toString())   // Punto(x=1, y=2): etiqueta no aparece
println(a.copy().etiqueta) // sin etiqueta: copy pierde el estado del cuerpo

Esa última línea es la que muerde en producción. copy invoca el constructor primario, de modo que los bloques init sí se ejecutan y las validaciones sí se aplican, pero cualquier propiedad del cuerpo vuelve a su valor de inicialización. Una data class con estado en el cuerpo no tiene un copy roto: tiene un copy que hace exactamente lo prometido, y lo prometido nunca incluyó ese estado.

Las restricciones estructurales completan el cuadro. El constructor primario debe existir y tener al menos un parámetro; todos sus parámetros deben ir marcados como val o var; y la clase no puede ser abstract, open, sealed ni inner. Sí puede implementar interfaces y sí puede heredar de otra clase, con la consecuencia incómoda de que el estado heredado queda fuera del equals generado.

Lo que una data class no genera nunca

Hay una asimetría más que casi nadie conoce y que conviene tener presente desde el primer día: si tú proporcionas una implementación explícita de equals, hashCode o toString en el cuerpo, el compilador deja de generar esa función concreta, pero sigue generando las otras dos. Escribir un equals a medida y olvidar hashCode no produce ningún error: produce una clase donde el hashCode generado sigue mirando todas las propiedades del constructor mientras tu equals mira otra cosa. El contrato queda roto en silencio. Con copy y componentN ocurre lo contrario: no puedes darles una implementación propia con la misma firma, el compilador lo rechaza.

Queda un último punto sobre las propiedades de coma flotante. En el equals y el hashCode generados, un Double o un Float se comparan con el orden total de Kotlin y no con la semántica IEEE 754 que aplica el operador == sobre tipos estáticamente conocidos. La consecuencia es que dentro de una data class, NaN es igual a NaN, y 0.0 no es igual a -0.0. Es la elección correcta para poder usar la instancia como clave de un mapa, pero contradice la intuición aritmética.

Comprobarlo en vez de creerlo

Nada de lo anterior hay que aceptarlo por fe: el código generado es inspeccionable y conviene mirarlo al menos una vez en la vida para que deje de ser una abstracción. En el backend de la JVM, la herramienta más directa es pedir el bytecode y descompilarlo a Java, cosa que el IDE ofrece en su menú de herramientas de Kotlin, o hacerlo desde la línea de órdenes:

kotlinc Usuario.kt -d salida
javap -p -c salida/UsuarioKt.class
javap -p salida/Usuario.class

Lo que aparece confirma las cinco familias y añade tres detalles que solo se ven ahí. Primero, equals no compara los objetos con una llamada directa a equals, sino a través de una función auxiliar de la biblioteca de intrínsecos que ya contempla los nulos, porque el == de Kotlin es seguro frente a referencias nulas. Segundo, junto a copy aparece un método sintético adicional, con el sufijo que denota los valores por defecto, que recibe una máscara de bits y decide para cada parámetro si usar el valor recibido o el actual: por eso el número de propiedades tiene un techo práctico y por eso copy no siempre se integra en el punto de llamada. Y tercero, las funciones componentN figuran como métodos públicos normales, lo cual deja claro que el orden de tu constructor es superficie pública real y no una convención interna.