El constructor primario: la firma que declara el estado

En Java, construir un objeto obliga a escribir tres veces lo mismo: el campo, el parámetro y la asignación que los une. Kotlin borra esa triple repetición metiendo la declaración de las propiedades dentro de la propia firma de la clase, y al hacerlo cambia algo más profundo que la ergonomía. El constructor primario deja de ser un método más para convertirse en la declaración del contrato mínimo que hace falta para que una instancia exista. Si un dato aparece ahí, ninguna instancia de esa clase podrá existir sin él, y el compilador lo garantiza sin que tú escribas ni una comprobación. Esta lección desmonta la sintaxis y, sobre todo, el orden exacto en que ocurren las cosas.

La firma que declara el estado

El constructor primario va pegado al nombre de la clase, y sus parámetros pueden llevar val o var. Esa palabra clave es la que decide si estás declarando un parámetro pasajero o una propiedad permanente:

class Usuario(val nombre: String, var edad: Int)

val u = Usuario("Ada", 36)
u.edad = 37          // hay setter porque se declaro var
// u.nombre = "otro" // error de compilacion: val no genera setter

Una sola línea produce, en la JVM, dos campos privados, dos getters y un setter. Pero la diferencia importante no es cuánto texto ahorras, sino qué ocurre cuando omites el val o el var. Sin ellos, el identificador sigue siendo un parámetro del constructor, y su vida termina en cuanto la inicialización acaba: puedes leerlo en los inicializadores de propiedad y en los bloques init, pero no existe en el cuerpo de ninguna función miembro, porque no se guardó en ningún sitio.

class Circulo(radio: Double) {              // parametro, no propiedad
    val area = Math.PI * radio * radio      // legal: la inicializacion aun corre
    // fun radioActual() = radio            // error: radio ya no existe aqui
}

Esa asimetría es una herramienta de diseño, no un detalle. Un parámetro sin val declara lo que hace falta para construir el objeto; una propiedad declara lo que el objeto recuerda. Cuando un dato solo sirve para calcular otra cosa —una semilla, una configuración que se traduce a otra representación, una fábrica que solo se usa una vez— dejarlo sin val impide que nadie lo retenga por accidente y reduce el estado que hay que razonar después.

init: el cuerpo troceado del constructor

El constructor primario no tiene cuerpo propio porque solo puede asignar. Todo lo demás —validar, derivar, registrar— vive en bloques init, que forman colectivamente el cuerpo de ese constructor:

class Cuenta(val titular: String, saldoInicial: Long) {

    var saldo: Long = saldoInicial
        private set

    init {
        require(titular.isNotBlank()) { "el titular no puede estar vacio" }
        require(saldoInicial >= 0) { "el saldo inicial no puede ser negativo" }
    }
}

Puede haber varios bloques init, y no es un capricho: permiten colocar cada validación junto a la propiedad que valida en vez de amontonarlas al final. El compilador los concatena en el orden en que aparecen, así que el efecto es idéntico al de un único bloque, pero el código se lee por temas y no por fases.

Aquí aparece la primera regla que separa a quien escribe clases de quien diseña tipos: si un constructor termina sin lanzar, el objeto queda válido por construcción. Toda comprobación que hagas en init es una comprobación que ninguna función miembro tendrá que repetir jamás, porque ya no existe forma de llegar a esas funciones con un objeto inválido. Trasladar validación del uso a la construcción no elimina el código: lo mueve a un sitio donde se ejecuta una vez y protege para siempre.

El orden de inicialización

El orden no es arbitrario ni depende de dónde declares las cosas visualmente por bloques: es estrictamente textual. Los inicializadores de propiedad y los bloques init se ejecutan intercalados, de arriba abajo, tal como aparecen en el cuerpo de la clase. Antes de todo eso corre el constructor de la superclase.

flowchart TD
A[Se evaluan los argumentos del constructor primario] --> B[Corre el constructor de la superclase]
B --> C[Inicializadores de propiedad y bloques init en orden textual]
C --> D[Cuerpo del constructor secundario si se entro por uno]
D --> E[Instancia lista y visible para el llamante]
style A fill:#89b4fa,color:#11111b
style C fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b

De ese diagrama sale una consecuencia incómoda que conviene interiorizar ahora. Cuando corre el constructor de la superclase, las propiedades de la subclase todavía no están inicializadas. Si la superclase llama en su constructor a un miembro open que la subclase sobrescribe, esa versión sobrescrita se ejecutará leyendo campos que aún valen cero o null, aunque el tipo diga que no pueden ser nulos.

open class Base(val etiqueta: String) {
    init { mostrar() }                       // peligro: llamada virtual desde el constructor
    open fun mostrar() = println(etiqueta)
}

class Derivada(etiqueta: String) : Base(etiqueta) {
    private val sufijo: String = "!!"        // aun no asignado cuando corre mostrar
    override fun mostrar() = println(etiqueta + sufijo.length)   // NullPointerException
}

Constructores secundarios: cuándo hacen falta

Un constructor secundario se declara con constructor y está obligado a delegar, con this, en el primario o en otro secundario que acabe llegando a él. Esa obligación existe justamente para que el camino de inicialización dibujado arriba no tenga atajos:

class Punto(val x: Int, val y: Int) {

    constructor(par: Pair<Int, Int>) : this(par.first, par.second)

    constructor(escalar: Int) : this(escalar, escalar) {
        // este cuerpo corre DESPUES de los init del primario
        require(escalar != 0) { "el punto diagonal cero no se admite" }
    }
}

La pregunta interesante no es cómo se escriben, sino por qué casi nunca hacen falta. Los parámetros con valor por defecto cubren el noventa por ciento de los casos por los que Java necesitaba sobrecargas, y lo hacen sin duplicar rutas de inicialización:

class Peticion(
    val url: String,
    val metodo: String = "GET",
    val reintentos: Int = 3,
)

Peticion("https://ejemplo.dev")
Peticion("https://ejemplo.dev", reintentos = 0)

Quedan tres motivos legítimos para un secundario: adaptar una firma ajena que no puedes cambiar, como el constructor de tres argumentos que exige una API de la plataforma; construir a partir de un tipo distinto que hay que traducir antes de delegar; y ofrecer sobrecargas reales a llamantes de Java, donde los valores por defecto no existen salvo que anotes con @JvmOverloads. Fuera de esos tres casos, un secundario suele ser una ruta de inicialización paralela, es decir, un sitio más donde las invariantes pueden romperse.

Existe también el caso extremo de una clase sin constructor primario. Entonces cada secundario invoca directamente a super, y los bloques init siguen ejecutándose antes que el cuerpo de cualquiera de ellos. Es la forma que adoptan casi siempre las jerarquías de excepciones, donde hay que replicar las cuatro firmas de Throwable:

class ErrorDeDominio : RuntimeException {
    constructor(mensaje: String) : super(mensaje)
    constructor(mensaje: String, causa: Throwable) : super(mensaje, causa)
}