Factorías e invoke: constructores que no son constructores

Un constructor es la operación más rígida que ofrece un lenguaje orientado a objetos: no tiene nombre propio, no puede fallar devolviendo nada, no puede elegir qué subtipo entrega, no puede reutilizar una instancia previa y no puede sobrecargarse por tipo de retorno. Cada una de esas rigideces es una restricción de diseño que, tarde o temprano, se convierte en un problema de API. El compañero de Kotlin ofrece la salida canónica: cierras el constructor, abres una fábrica y recuperas todos los grados de libertad que el constructor te negaba. Y si te duele que el sitio de llamada pierda el aspecto de una construcción, el operador invoke te lo devuelve intacto. La pregunta interesante no es cómo se escribe, que es trivial, sino qué le estás ocultando a quien lee tu código y si ese ocultamiento está justificado.

Cerrar el constructor para abrir opciones

El patrón base consiste en marcar el constructor primario como privado y dejar que el compañero sea la única puerta de entrada. Como el compañero está dentro de la clase, ve el constructor privado sin problemas.

@JvmInline
value class Correo private constructor(val valor: String) {
    companion object {
        private val PATRON = Regex("""^[^@\s]+@[^@\s]+\.[a-z]{2,}$""")

        fun crear(bruto: String): Correo? {
            val limpio = bruto.trim().lowercase()
            return if (PATRON.matches(limpio)) Correo(limpio) else null
        }

        fun exigir(bruto: String): Correo =
            crear(bruto) ?: throw IllegalArgumentException("correo invalido")
    }
}

La diferencia con validar dentro de un bloque init y lanzar una excepción no es estilística, es de teoría de tipos. Un constructor que lanza es una función parcial disfrazada de total: su firma promete devolver siempre un valor y en realidad no lo hace, de modo que el error queda fuera del sistema de tipos y solo se descubre leyendo la documentación o el código. Una fábrica que devuelve un tipo anulable o un Result convierte esa parcialidad en información que el compilador puede exigir que trates. Es la misma idea que sostiene toda la nulabilidad de Kotlin, aplicada a la construcción.

Hay un matiz de diseño en la pareja de fábricas del ejemplo que conviene no perder. Ofrecer a la vez una versión que devuelve nulo y otra que lanza no es redundancia: son dos contratos para dos situaciones distintas. La primera sirve cuando el dato viene de fuera y el fallo es esperable, como al validar un formulario; la segunda sirve cuando el dato viene de una constante del propio código y un fallo indicaría un error de programación. Nombrarlas de forma distinta obliga a quien llama a elegir conscientemente, que es exactamente lo que un constructor único impide.

Las otras tres libertades aparecen en cuanto miras qué más puede hacer un método que un constructor no.

El compañero que se hace pasar por constructor

El coste de todo lo anterior es un sitio de llamada que cambia de aspecto: se pasa de Correo("a@b.co") a Correo.crear("a@b.co"). Cuando esa diferencia molesta, el operador invoke la borra. Si el compañero define operator fun invoke, entonces escribir el nombre de la clase seguido de paréntesis se resuelve como una llamada a ese operador sobre el compañero.

class Duracion private constructor(val nanos: Long) {
    companion object {
        private val CACHE = Array(1024) { Duracion(it.toLong()) }

        operator fun invoke(nanos: Long): Duracion =
            if (nanos in 0 until 1024) CACHE[nanos.toInt()] else Duracion(nanos)
    }
}

val d = Duracion(42)   // parece un constructor, es Duracion.Companion.invoke

El mecanismo conviene tenerlo claro para no llevarse sorpresas. La expresión con paréntesis busca primero un constructor aplicable y, si lo encuentra, gana; solo cuando no hay constructor accesible que encaje entra en juego el invoke del compañero. Por eso el patrón exige de verdad que el constructor sea privado: si dejas uno público con la misma firma, tu invoke quedará como código muerto y la caché nunca se usará. Y por eso mismo mezclar ambas cosas con firmas parecidas es una fuente sólida de confusión en revisiones de código.

flowchart TD
L[Sitio de llamada con nombre de tipo y parentesis] --> R[Resolucion de sobrecarga]
R --> C[Existe constructor accesible y aplicable]
R --> I[No hay constructor aplicable]
C --> C2[Se invoca el constructor y el invoke queda ignorado]
I --> I2[Se busca operator invoke en el companion]
I2 --> I3[Se ejecuta la fabrica con validacion o cache o subtipo]
style C2 fill:#f38ba8,color:#11111b
style I3 fill:#a6e3a1,color:#11111b

Hay una alternativa que la biblioteca estándar usa más que el invoke y que conviene poner en la balanza: la función de nivel superior con el mismo nombre que el tipo, escrita con mayúscula inicial. Construcciones muy usadas del ecosistema se crean así, y el efecto visual es idéntico al de un constructor. Sus ventajas son que no obliga a existir un compañero, que se importa y se descubre como cualquier función, y que desde Java se ve como un método estático del fichero. Su desventaja es que no se hereda: si diseñas una interfaz cuyos implementadores deben aportar una fábrica, solo el compañero que implementa esa interfaz te da ese contrato.

Tres formas de construir y cómo se decide

Puestas en fila, las tres opciones se distinguen por lo que prometen y por lo que cuesta cambiarlas más adelante.

// 1. Constructor publico: maxima transparencia, minima libertad futura
class Punto(val x: Int, val y: Int)

// 2. Fabrica con nombre en el companion: libertad total, sitio de llamada explicito
class Color private constructor(val rgb: Int) {
    companion object {
        fun deHex(s: String): Color? = s.removePrefix("#").toIntOrNull(16)?.let(::Color)
    }
}

// 3. Funcion de nivel superior con nombre de tipo: aspecto de constructor sin companion
fun Temporizador(ms: Long): Temporizador = TemporizadorReal(ms)

El criterio que mejor aguanta el paso del tiempo es el de compatibilidad. Un constructor público forma parte del artefacto compilado con una firma exacta, y cualquier cambio en su lista de parámetros rompe a los consumidores ya compilados aunque el código fuente siga compilando. Añadir un parámetro con valor por defecto, que en Kotlin parece inocuo, genera una firma sintética adicional y deja obsoleta la anterior. Una fábrica con nombre no tiene ese problema porque puedes añadir una nueva y marcar la vieja como obsoleta durante una o dos versiones, que es la única forma civilizada de evolucionar una biblioteca con usuarios.

El segundo criterio es la herencia del contrato. Si diseñas una interfaz cuyos implementadores deben ofrecer una forma de construirse, la única de las tres opciones que lo expresa es el compañero que implementa esa interfaz de fábrica, porque solo él puede aparecer como valor y recibirse por parámetro. Ni un constructor ni una función libre pueden cumplir un contrato declarado.

El tercero es puramente ergonómico y es donde entra invoke: si el sitio de llamada ideal es el nombre del tipo seguido de argumentos, tienes dos caminos, el operador en el compañero y la función de nivel superior con mayúscula. La función libre gana en simplicidad y en interoperabilidad; el operador gana cuando además necesitas que esa fábrica sea heredable o accesible de forma genérica a través del compañero.

Queda un cuarto criterio, más silencioso, que aparece cuando la clase es una clase de valor en línea. Al cerrar el constructor y validar en la fábrica obtienes el patrón del tipo refinado: un envoltorio que no cuesta nada en tiempo de ejecución y del que, sin embargo, no puede existir ninguna instancia inválida en todo el programa. Esa combinación es la razón principal por la que el patrón merece la pena en dominios donde una cadena mal formada llega hasta la base de datos.

@JvmInline
value class Identificador private constructor(private val v: String) {
    companion object {
        fun de(bruto: String): Identificador? =
            bruto.takeIf { it.length == 26 && it.all(Char::isLetterOrDigit) }
                ?.let(::Identificador)
    }

    override fun toString(): String = v
}

A partir de ahí, cualquier función que reciba un Identificador puede prescindir de validaciones defensivas, porque la única puerta de entrada al tipo ya las hizo. Ese es el rendimiento real de cerrar un constructor: no ahorra líneas, elimina una clase entera de comprobaciones repetidas y el estado de programa que las hacía necesarias.