fun interface: un método abstracto, un nombre y una conversión

Kotlin tiene dos maneras de expresar aquí va un comportamiento: el tipo función, que es anónimo, estructural y nativo del lenguaje, y la interfaz funcional, que es nominal, extensible y heredada de la tradición de la JVM. Durante años la segunda solo estuvo disponible para interfaces escritas en Java, porque el compilador aplicaba conversión SAM automática al interoperar y no a los tipos propios. La palabra clave fun delante de interface cerró esa asimetría y abrió una decisión de diseño que ahora hay que tomar conscientemente en cada API pública. No es una cuestión de gusto: las dos opciones se compilan de forma distinta, se comportan distinto ante la sobrecarga y ante los tipos primitivos, y una de ellas es incompatible con la optimización más importante que tiene Kotlin para funciones de orden superior.

Un método abstracto y un nombre propio

Una interfaz funcional es una interfaz con exactamente un miembro abstracto, y ese miembro tiene que ser una función. Puede tener todos los métodos con cuerpo que quieras, un companion object y extensiones; lo que no puede tener es una segunda función abstracta ni una propiedad abstracta, porque una propiedad abstracta esconde uno o dos accesores abstractos y rompería la cuenta.

fun interface Validador {
    fun valida(entrada: String): Boolean

    fun y(otro: Validador) = Validador { valida(it) && otro.valida(it) }

    companion object {
        val NoVacio = Validador { it.isNotBlank() }
    }
}

val correo = Validador { it.contains("@") }
val fuerte = Validador.NoVacio.y(correo)

Fíjate en lo que acaba de ocurrir dos veces: donde se espera un Validador has escrito una lambda. Eso es la conversión SAM, y solo funciona porque la interfaz está marcada con fun. Sin esa marca tendrías que escribir un object : Validador completo. Con interfaces declaradas en Java la conversión siempre ha sido automática, porque Java carece de tipos función y sin ella la interoperabilidad sería insoportable.

La conversión exige que el tipo esperado sea conocido en el punto de la expresión: funciona en un argumento, en una asignación con tipo declarado o en un retorno tipado, y no funciona si escribes la lambda suelta y esperas que el compilador adivine. También existe la referencia al constructor de la interfaz funcional, ::Validador, que produce una función capaz de envolver un tipo función en el tipo nominal; es la herramienta de migración cuando quieres sustituir un typealias sobre un tipo función por una interfaz de verdad sin romper a quien ya llamaba.

Que la casilla abstracta esté limitada a una función y no admita propiedades es una regla con motivo, no un descuido. Una propiedad abstracta esconde uno o dos accesores, así que aceptarla obligaría a definir a cuál de ellos corresponde la lambda y convertiría una regla trivial de contar en una casuística. Kotlin prefiere la regla trivial, y si necesitas un contrato con un dato y una operación, eso ya no es una interfaz funcional: es una interfaz normal, y esconderla tras una lambda solo confundiría a quien la lea.

Qué genera la conversión

Al principio, cada lambda convertida por SAM producía una clase anónima en el bytecode: un fichero más por cada punto de conversión y un objeto nuevo por cada evaluación. Desde Kotlin 1.5 el modo por defecto usa invokedynamic con la fábrica de lambdas de la plataforma, de modo que la clase se sintetiza en tiempo de ejecución la primera vez y las lambdas sin capturas se reutilizan como instancia única.

flowchart LR
L[Lambda en el codigo fuente] --> C[Conversion SAM del compilador]
C --> I[Instruccion invokedynamic]
I --> F[Fabrica de lambdas de la plataforma]
F --> O[Instancia del tipo funcional]
O --> U[Uso como cualquier objeto]

La consecuencia práctica es que el argumento las interfaces funcionales generan basura de clases dejó de ser cierto hace muchas versiones. Lo que sigue siendo cierto es que la conversión produce un objeto, con su identidad y su ciclo de vida. Dos lambdas idénticas escritas en sitios distintos no son iguales entre sí: la igualdad de un Validador es la de Any, no la de su comportamiento, y eso importa cuando registras y das de baja escuchadores.

Fuera de la JVM el mecanismo cambia, pero el modelo semántico no: una interfaz funcional es un tipo nominal cuyas instancias pueden crearse con sintaxis de lambda.

Conviene además saber dónde no se aplica la conversión. No se aplica si el tipo esperado no está determinado, de modo que val v = { s: String -> s.isNotEmpty() } produce un tipo función y no un Validador por mucho que uno exista con esa forma. No se aplica sobre interfaces con dos miembros abstractos ni sobre interfaces normales sin la marca fun, donde tendrás que escribir el objeto anónimo completo. Y no se aplica hacia atrás: teniendo un Validador en la mano, pasarlo donde se espera (String) -> Boolean requiere una referencia al método, porque el tipado nominal no se convierte solo en estructural.

val v: Validador = Validador { it.isNotBlank() }
val f: (String) -> Boolean = v::valida        // del nombre a la forma
val g: Validador = ::comprobar                 // de la funcion al nombre
fun comprobar(entrada: String) = entrada.length > 3

Cuándo el nombre gana

Hay cuatro razones sólidas para preferir una interfaz funcional a un tipo función, y ninguna es estética.

La primera es la sobrecarga. En la JVM, (String) -> Unit y (Int) -> Unit acaban siendo el mismo tipo tras el borrado, así que dos funciones que solo se distingan por eso chocan. Dos interfaces funcionales distintas nunca chocan, porque son tipos distintos también en el bytecode.

Esa colisión no es un caso raro: aparece en cuanto una API ofrece dos formas de configurar lo mismo, una con un valor y otra con un proveedor, o dos variantes de una operación que difieren solo en el tipo del parámetro devuelto. Con tipos función hay que renombrar una de las dos; con tipos nominales no hay nada que renombrar.

La segunda es el boxing. Un tipo función sobre primitivos se representa con el tipo genérico de la biblioteca, y los genéricos de la JVM no admiten primitivos: cada Int que atraviesa la frontera se envuelve. Una interfaz funcional con parámetros primitivos conserva el primitivo.

// Cada llamada envuelve el Int y desenvuelve el Boolean.
val caro: (Int) -> Boolean = { it % 2 == 0 }

// Ninguna envoltura: la firma usa el primitivo.
fun interface PredicadoInt {
    fun test(valor: Int): Boolean
}
val barato = PredicadoInt { it % 2 == 0 }

La tercera es que un tipo con nombre puede llevar equipaje: métodos por defecto que componen, un companion object con instancias canónicas, documentación adherida al tipo y no al parámetro. La cuarta es la interoperabilidad: desde Java, un parámetro de tipo función aparece como el tipo genérico de la biblioteca de Kotlin, feo y con Unit de retorno explícito; una interfaz funcional aparece como lo que es.

Migrar sin romper a nadie

El caso práctico más frecuente no es elegir desde cero, sino descubrir a mitad de camino que un tipo función que empezó siendo un detalle interno se ha convertido en parte de la API pública. Kotlin permite hacer esa transición de forma casi indolora, y merece la pena conocer el orden de los pasos.

// Antes: nombre para el lector, ningún tipo nuevo.
typealias Transformador = (String) -> String

// Después: tipo real, con sitio para crecer.
fun interface Transformador {
    fun aplicar(entrada: String): String

    fun luego(otro: Transformador) =
        Transformador { otro.aplicar(aplicar(it)) }
}

Toda llamada que pasaba una lambda sigue compilando gracias a la conversión SAM. Lo que deja de compilar es el código que trataba el valor como función y lo invocaba con paréntesis o lo componía con operaciones de tipos función; para esos sitios existen la referencia al método y la referencia al constructor de la interfaz funcional, que hacen de puente en ambas direcciones mientras dura la migración.

La lección de fondo es que la dirección fácil es de forma a nombre. Empezar con un tipo función y ascender a interfaz funcional cuando el concepto se consolida cuesta poco; empezar con una interfaz funcional y descubrir que hacía falta que fuese insertable en línea cuesta reescribir la firma y a todos sus llamadores. En la duda, y para código interno, el tipo función es la apuesta reversible.