Diseñar con extensiones: cuándo sí y cuándo es un tipo que falta

Las cuatro lecciones anteriores describen una herramienta con un mecanismo simple y unos límites nítidos: función estática, resolución léxica, sin estado, sin polimorfismo. Esta trata del único problema que queda, que no es técnico sino de juicio. Las extensiones son tan cómodas de escribir que se escriben sin pensar, y un proyecto de cierta edad suele acumular decenas de operaciones colgadas de String, de Int y de List que en conjunto forman un lenguaje de dominio no declarado, sin tipos, sin invariantes y sin nadie que lo mantenga. El síntoma no es que cada extensión sea mala. Cada una, aislada, parecía la decisión correcta. El problema es que la suma de decisiones correctas puede ser una arquitectura que no eligió nadie, y reconocer el momento en que eso empieza a pasar es lo que distingue a quien diseña de quien acumula.

Cuándo una extensión mejora una API ajena

El caso fuerte es siempre el mismo: el tipo no es tuyo y la operación depende solo de su contrato público. Ahí la extensión es superior a todas las alternativas, y conviene ver por qué comparándola con lo que haría falta sin ella.

// El tipo viene de una libreria y no se puede tocar
fun java.time.Instant.enZonaLocal(): java.time.LocalDateTime =
    java.time.LocalDateTime.ofInstant(this, java.time.ZoneId.systemDefault())

// Encadena con lo que ya existe, sin envoltorio ni conversion
val texto = instante.enZonaLocal().formatoCorto()

Un envoltorio resolvería lo mismo a costa de una clase nueva, un constructor, un método de desempaquetado y la obligación de convertir en cada frontera con la librería. Una función libre enZonaLocal(instante) resolvería lo mismo a costa de romper el encadenamiento y forzar la lectura de dentro hacia fuera. La extensión no cuesta ni asignación ni conversión y deja la línea legible de izquierda a derecha.

La prueba de que el caso es fuerte está en las tres condiciones que se cumplen a la vez: no puedes tocar el tipo, no necesitas tocarlo porque su API pública basta, y a nadie se le ocurriría querer una versión distinta de la operación para una subclase de Instant, entre otras cosas porque Instant es final. Cuando las tres se dan, no hay ninguna alternativa mejor y la discusión se acaba ahí.

Cuándo esconde una abstracción que falta

El caso débil también tiene una firma reconocible, y son cinco síntomas. Aparecen juntos con mucha frecuencia.

El primero es el receptor demasiado general. Cuando lees fun String.esDniValido(), fun String.formatearComoIban() y fun String.normalizarTelefono() en el mismo archivo, lo que hay delante no son tres operaciones sobre cadenas: son tres tipos de dominio que nadie ha declarado, todos representados por el mismo String que también representa nombres, rutas y mensajes de error. El compilador no puede impedir que pases un teléfono donde se espera un DNI, porque para él ambos son la misma cosa.

El segundo es el grupo con invariante común. Si diez extensiones sobre el mismo tipo comparten una precondición implícita —que la cadena venga ya normalizada, que la lista esté ordenada, que el mapa contenga cierta clave—, ese invariante quiere ser un tipo cuyo constructor lo garantice una vez, en lugar de una suposición repetida diez veces y verificada ninguna.

El tercero es la necesidad de estado. En cuanto una extensión quiere recordar algo entre llamadas, cachear un resultado o llevar una configuración, la respuesta correcta es una clase. Los mapas externos con claves débiles que a veces se usan para simular estado asociado son un mecanismo de último recurso con coste de memoria y trampas de concurrencia.

El cuarto es el deseo de polimorfismo. Si te ves escribiendo una extensión con un when sobre subtipos, o dos extensiones para dos ramas de una jerarquía, lo que pides es un método virtual y el sitio de un método virtual es la interfaz. La segunda lección de este nivel explica exactamente por qué la extensión no va a servir.

El quinto es el problema de descubrimiento. Una extensión existe solo donde se importa, así que quien no sepa que existe no la va a encontrar. Con cinco es irrelevante; con ciento cincuenta repartidas por ocho paquetes, la operación que ya está escrita se reescribe una y otra vez porque nadie la ve.

El diagnóstico rápido cabe en un vistazo al archivo:

// Sintoma: tres tipos de dominio disfrazados del mismo String
fun String.esDniValido(): Boolean = TODO()
fun String.formatearComoIban(): String = TODO()
fun String.normalizarTelefono(): String = TODO()

// Y la firma que lo delata
fun registrar(dni: String, iban: String, telefono: String) = TODO()

Esa última línea admite los tres argumentos en cualquier orden sin que nada se queje. El compilador tiene todo lo necesario para impedirlo y no lo hace porque nadie le ha contado que son cosas distintas.

flowchart TB
s[operacion nueva sobre un tipo] --> q1{es tuyo el tipo}
q1 -->|si| mem[normalmente va como miembro]
q1 -->|no| q2{depende solo de la API publica}
q2 -->|no| env[hace falta un envoltorio o un tipo propio]
q2 -->|si| q3{el receptor representa tu concepto}
q3 -->|no| tipo[falta un tipo de dominio]
q3 -->|si| q4{alguien querria especializarla}
q4 -->|si| iface[hace falta una interfaz]
q4 -->|no| ext[extension justificada]

Las cuatro preguntas antes de escribirla

La refactorización que resuelve el caso débil casi siempre es la misma, y es más barata de lo que parece:

@JvmInline
value class Telefono private constructor(val e164: String) {
    companion object {
        fun de(bruto: String): Telefono? =
            bruto.filter { it.isDigit() || it == '+' }
                .takeIf { it.length in 8..15 }
                ?.let { Telefono(it) }
    }
    val prefijoPais: String get() = e164.takeWhile { it != ' ' }
    fun enmascarado(): String = e164.dropLast(4) + "****"
}

Las tres extensiones sobre String se convierten en un tipo con un constructor que valida una vez, miembros que ya no necesitan repetir precondiciones, y una firma que impide confundir un teléfono con un DNI. Como value class, además, no hay instancia en el montón en el caso general: la abstracción se paga en tiempo de compilación y desaparece en ejecución. Ese es el intercambio que casi siempre conviene tomar.

Conviene notar que la refactorización no elimina las extensiones, las recoloca. Sigue habiendo sitio para fun Telefono.enWhatsapp(): String en el módulo que hable con ese servicio, y ahora es una extensión ejemplar: el receptor representa exactamente el concepto del que trata la operación, el invariante ya está garantizado por el constructor y el módulo de mensajería no tiene por qué figurar en el tipo del dominio. La diferencia entre la extensión buena y la mala no está en la sintaxis sino en si el sustantivo existía antes de escribirla.