Guía del usuario de Vavr

Las aplicaciones Java suelen estar llenas de side-effects. Estos mutan algún tipo de estado, tal vez el mundo exterior. Los efectos secundarios comunes incluyen cambiar objetos o variables en el lugar, imprimir en la consola, escribir en un archivo de registro o en una base de datos. Los efectos secundarios se consideran perjudiciales si afectan la semántica de nuestro programa de manera no deseada.

Por ejemplo, si una función lanza una excepción y esta excepción es interpretada, se considera un efecto secundario que afecta nuestro programa. Además, las excepciones son como declaraciones goto no locales. Rompen el flujo de control normal. Sin embargo, las aplicaciones del mundo real realizan efectos secundarios.

En un entorno funcional, estamos en la situación favorable de encapsular el efecto secundario en un Try:

Esta versión de divide ya no lanza ninguna excepción. Hicimos que el posible fallo sea explícito al usar el tipo Try

Una función, o más generalmente una expresión, se denomina referencialmente transparente si una llamada puede ser reemplazada por su valor sin afectar el comportamiento del programa. Dicho de manera sencilla, dado el mismo input, la salida siempre será la misma.

Una función se llama pura si todas las expresiones involucradas son referencialmente transparentes. Una aplicación compuesta por funciones puras probablemente simplemente funcione si compila. Podemos razonar sobre ella. Las pruebas unitarias son fáciles de escribir y la depuración se convierte en un vestigio del pasado.

Rich Hickey, el creador de Clojure, dio una charla excepcional sobre El Valor de los Valores. Los valores más interesantes son los valores immutable. La razón principal es que los valores inmutables:

La clave para mejorar Java es usar valores inmutables junto con funciones referencialmente transparentes.

Vavr proporciona los controles y las colecciones necesarios para lograr este objetivo en la programación cotidiana en Java.

Java es un lenguaje de programación orientado a objetos. Encapsulamos el estado en objetos para lograr ocultar los datos y proporcionamos métodos mutadores para controlar dicho estado. El framework de colecciones de Java (JCF) se basa en esta idea.

Hoy en día, considero que un tipo de retorno void es un indicio de mal diseño. Es evidencia de que ocurren efectos secundarios y de que el estado se está mutando. El estado mutable Shared es una fuente importante de fallos, no solo en un entorno concurrente.

Las estructuras de datos Immutables no pueden modificarse después de su creación. En el contexto de Java, se utilizan ampliamente en forma de wrappers de colecciones.

Existen varias bibliotecas que nos proporcionan métodos de utilidad similares. El resultado siempre es una vista no modificable de la colección específica. Por lo general, lanzará una excepción en tiempo de ejecución si llamamos a un método mutador.

Una estructura de datos persistente conserva la versión anterior de sí misma cuando se modifica, y por lo tanto es efectivamente inmutable. Las estructuras de datos completamente persistentes permiten tanto actualizaciones como consultas en cualquier versión.

Muchas operaciones realizan solo pequeños cambios. Simplemente copiar la versión anterior no sería eficiente. Para ahorrar tiempo y memoria, es crucial identificar las similitudes entre dos versiones y compartir la mayor cantidad de datos posible.

Este modelo no impone ningún detalle de implementación específico. Aquí es donde entran en juego las estructuras de datos funcionales.

Una de las estructuras de datos funcionales más populares y también más simples es la lista enlazada (singly) linked List. Esta estructura tiene un elemento principal head y una lista tail (cola). Una lista enlazada se comporta como una pila (Stack) que sigue el método último en entrar, primero en salir (LIFO).

En Vavr, podemos instanciar una lista de la siguiente manera:

Cada elemento de la lista forma un nodo separado de la lista. La cola (tail) del último elemento es Nil, que representa la lista vacía.

Esto nos permite compartir elementos entre diferentes versiones de la lista.

El nuevo elemento principal 0 está vinculado a la cola de la lista original. La lista original permanece sin modificar.

Estas operaciones se realizan en tiempo constante, es decir, son independientes del tamaño de la lista. La mayoría de las otras operaciones toman tiempo lineal. En Vavr, esto se expresa mediante la interfaz LinearSeq, que ya conocemos de Scala.

Si necesitamos estructuras de datos que permitan consultas en tiempo constante, Vavr ofrece Array y Vector. Ambos tienen capacidades de acceso aleatorio.

El tipo Array está respaldado por un array de objetos de Java. Las operaciones de inserción y eliminación toman tiempo lineal. Él Vector está entre Array y List. Tiene un buen rendimiento tanto en acceso aleatorio como en modificaciones.

De hecho, la lista enlazada también puede utilizarse para implementar una estructura de datos tipo cola (Queue).

Una cola funcional muy eficiente puede implementarse utilizando dos listas enlazadas. La lista front contiene los elementos que se eliminan de la cola, mientras que la lista rear contiene los elementos que se agregan. Ambas operaciones, enqueue y dequeue, se realizan en tiempo O(1).

La cola inicial se crea con tres elementos. Luego, se agregan dos elementos en la lista rear.

Si la lista front se queda sin elementos al hacer dequeue, la lista rear se invierte y se convierte en la nueva lista front.

Al hacer dequeue de un elemento, obtenemos un par que incluye el primer elemento y la cola restante. Es necesario devolver la nueva versión de la cola porque las estructuras de datos funcionales son inmutables y persistentes. La cola original no se ve afectada.

¿Qué sucede cuando la cola está vacía? En ese caso, dequeue() lanzará una excepción NoSuchElementException. Para hacerlo de manera funcional, esperaríamos más bien un resultado opcional.

Un resultado opcional puede procesarse aún más, ya sea que esté vacío o no.

Los conjuntos ordenados son estructuras de datos que se utilizan con más frecuencia que las colas. Utilizamos árboles binarios de búsqueda para modelarlos de manera funcional. Estos árboles están compuestos por nodos que pueden tener hasta dos hijos y valores en cada nodo.

Construimos árboles binarios de búsqueda bajo la presencia de un orden, representado por un Comparator. Todos los valores del subárbol izquierdo de cualquier nodo dado son estrictamente menores que el valor del nodo. Todos los valores del subárbol derecho son estrictamente mayores.

Las búsquedas en este tipo de árboles se realizan en tiempo O(log n). Comenzamos la búsqueda en la raíz y determinamos si encontramos el elemento. Debido al orden total de los valores, sabemos hacia dónde buscar a continuación, en la rama izquierda o derecha del árbol actual.

La mayoría de las operaciones sobre árboles son intrínsecamente recursivas. La función de inserción se comporta de manera similar a la función de búsqueda. Cuando se alcanza el final de un camino de búsqueda, se crea un nuevo nodo y se reconstruye todo el camino hasta la raíz. Siempre que sea posible, los nodos hijos existentes se reutilizan. Por lo tanto, la operación de inserción toma tiempo y espacio O(log n).

Para mantener las características de rendimiento de un árbol binario de búsqueda, debe mantenerse equilibrado. Todos los caminos desde la raíz hasta una hoja deben tener aproximadamente la misma longitud.

En Vavr, implementamos un árbol binario de búsqueda basado en un Red/Black Tree (Árbol Rojo/Negro). Este utiliza una estrategia de coloración específica para mantener el equilibrio del árbol durante las operaciones de inserción y eliminación. Para obtener más información sobre este tema, se recomienda leer el libro Purely Functional Data Structures de Chris Okasaki.

Comenzamos nuestro viaje implementando tipos secuenciales. Ya describimos la lista enlazada anteriormente. Luego siguió el Stream, una lista enlazada perezosa (lazy) que nos permite procesar secuencias de elementos posiblemente infinitas.

Todas las colecciones son Iterable y, por lo tanto, pueden usarse en bucles for mejorados.

Podemos lograr lo mismo internalizando el bucle e inyectando el comportamiento usando una lambda.

De todos modos, como vimos anteriormente, preferimos expresiones que devuelvan un valor sobre instrucciones que no devuelven nada. Observando un ejemplo simple, pronto reconoceremos que las instrucciones añaden ruido y separan lo que pertenece junto.

Las colecciones de Vavr nos proporcionan muchas funciones para operar sobre los elementos subyacentes. Esto nos permite expresar las cosas de manera muy concisa.

La mayoría de los objetivos se pueden lograr de diversas maneras usando Vavr. Aquí reducimos todo el cuerpo del método a llamadas de función fluidas en una instancia de List. Incluso podríamos eliminar todo el método y usar directamente nuestra lista para obtener el resultado de la computación.

En una aplicación del mundo real, ahora podemos reducir drásticamente el número de líneas de código y, por lo tanto, disminuir el riesgo de errores.

Las secuencias son geniales. Pero, para ser completos, una biblioteca de colecciones también necesita diferentes tipos de Set y Map.

Describimos cómo modelar conjuntos ordenados con estructuras de árboles binarios. Un Map ordenado no es más que un Set ordenado que contiene pares clave-valor y que tiene un orden para las claves.

La implementación de HashMap se respalda mediante un Hash Array Mapped Trie (HAMT). En consecuencia, el HashSet está respaldado por un HAMT que contiene pares clave-clave.

Nuestro Map no tiene un tipo especial de Entry para representar pares clave-valor. En su lugar, usamos Tuple2, que ya es parte de Vavr. Los campos de un Tuple están enumerados.

Los Map y Tuple se utilizan ampliamente en Vavr. Los Tuple son esenciales para manejar tipos de retorno con múltiples valores de forma general.

En Vavr, exploramos y probamos nuestra biblioteca implementando los 99 problemas de Euler. Es una excelente prueba de concepto. No dudes en enviar solicitudes de pull.

Agrega el repositorio adicional de snapshots en tu archivo build.gradle:

Asegúrate de que tu archivo ~/.m2/settings.xml contenga lo siguiente:

Aquí tienes un ejemplo de cómo crear una tupla que contiene un String y un Integer:

El mapeo elemento por elemento evalúa una función por cada elemento de la tupla, devolviendo otra tupla.

También es posible mapear una tupla usando una sola función de mapeo.

La transformación crea un nuevo tipo basado en el contenido de la tupla.

Puedes componer funciones. En matemáticas, la composición de funciones es la aplicación de una función al resultado de otra para producir una tercera función. Por ejemplo, las funciones f : X → Y and g : Y → Z pueden componerse para generar una función h: g(f(x)) que mapea X → Z.
Puedes usar andThen:

o compose:

Puedes elevar una función parcial a una función total que devuelve un resultado de tipo Option. El término partial function proviene de las matemáticas. Una función parcial de X a Y es una función f: X′ → Y, para algún subconjunto X′ de X. Generaliza el concepto de una función f: X → Y al no forzar que f asocie cada elemento de X a un elemento de Y. Esto significa que una función parcial funciona correctamente solo para algunos valores de entrada. Si se llama a la función con un valor de entrada no permitido, normalmente lanzará una excepción.

El siguiente método divide es una función parcial que solo acepta divisores distintos de cero.

Usamos lift para convertir divide en una función total que está definida para todas las entradas.

El siguiente método sum es una función parcial que solo acepta valores de entrada positivos.

Podemos elevar el método sum proporcionando la referencia al método.

La aplicación parcial te permite derivar una nueva función a partir de una existente fijando algunos valores. Puedes fijar uno o más parámetros, y el número de parámetros fijados define la aridad de la nueva función, de manera que new arity = (original arity - fixed parameters). Los parámetros se asignan de izquierda a derecha.

Esto puede demostrarse fijando los primeros tres parámetros de una Function5, lo que resulta en una Function2.

La aplicación parcial difiere de la Currificación (Currying), como se explorará en la sección correspondiente.

La currificación es una técnica que permite aplicar parcialmente una función fijando un valor para uno de los parámetros, lo que da como resultado una función Function1 que devuelve otra función Function1.

Cuando una Function2 es curried, el resultado es indistinguible de la aplicación parcial de una Function2 ya que ambas producen una función de aridad 1.

Podrás notar que, aparte del uso de .curried(), este código es idéntico al ejemplo de aridad 2 dado en Aplicación Parcial. Con funciones de mayor aridad, la diferencia se vuelve evidente.

La memoización es una forma de almacenamiento en caché. Una función memoizada se ejecuta solo una vez y luego devuelve el resultado desde una caché.
El siguiente ejemplo calcula un número aleatorio en la primera invocación y devuelve el número almacenado en caché en la segunda invocación.

Option es un tipo de contenedor monádico que representa un valor opcional. Las instancias de Option son ya sea una instancia de Some o None.

Si vienes a Vavr después de usar la clase Optional de Java, hay una diferencia crucial. En Optional, una llamada a .map que resulta en un valor null producirá un Optional vacío. En Vavr, esto generaría un Some(null), lo que podría llevar a un NullPointerException.

Usando Optional, este escenario es válido.

Usando la Option de Vavr, el mismo escenario resultará en un NullPointerException.

Esto puede parecer que la implementación de Vavr está rota, pero en realidad no lo está. Más bien, se adhiere al requisito de una mónada (monad) de mantener el contexto computacional al llamar a .map. En términos de una Option, esto significa que llamar a .map en un Some dará como resultado un Some y llamar a .map en un None dará como resultado un None. En el ejemplo de Optional de Java mencionado anteriormente, ese contexto cambió de un Some a un None.

Esto puede parecer que hace que Option sea inútil, pero en realidad te obliga a prestar atención a las posibles ocurrencias de null y a manejarlas adecuadamente en lugar de aceptarlas sin saberlo. La forma correcta de manejar las ocurrencias de null es usar flatMap.

Alternativamente, mueve el .flatMap para que esté ubicado junto al valor que posiblemente sea null.

Esto se explora en más detalle en el blog de Vavr.

Try es un tipo de contenedor monádico que representa una computación que puede resultar en una excepción o devolver un valor calculado exitosamente. Es similar a Either, pero semánticamente diferente. Una instancia de Try puede ser una instancia de Success o Failure.

Lazy es un tipo de contenedor monádico que representa un valor evaluado de forma perezosa (lazy). En comparación con un Supplier, Lazy realiza memoización, es decir, se evalúa solo una vez y, por lo tanto, es referencialmente transparente.

También puedes crear un valor realmente perezoso (lazy) (esto solo funciona con interfaces):

Either representa un valor de dos tipos posibles. Un Either es, o bien un Left, o bien un Right. Si un Either dado es un Right y se proyecta a un Left, las operaciones de Left no tienen efecto sobre el valor de Right. Si un Either dado es un Left y se proyecta a un Right, las operaciones de Right no tienen efecto sobre el valor de Left. Si un Left se proyecta a un Left, o un Right se proyecta a un Right, las operaciones sí tienen efecto.

Ejemplo: Una función compute(), que da como resultado un valor de tipo Integer (en el caso de éxito) o un mensaje de error de tipo String (en el caso de fallo). Por convención, el caso de éxito es Right y el de fallo es Left.

Si el resultado de compute() es Right(1), el valor es Right(2).
Si el resultado de compute() es Left("error"), el valor es Left("error").

Un Future es el resultado de una computación que estará disponible en algún momento. Todas las operaciones proporcionadas son no bloqueantes. El ExecutorService subyacente se utiliza para ejecutar controladores asíncronos, por ejemplo, mediante onComplete(…​).

Un Future tiene dos estados: pendiente y completado.

Pendiente: La computación está en curso. Solo un Future pendiente puede completarse o cancelarse.

Completado: La computación finalizó exitosamente con un resultado, falló con una excepción o fue cancelada.

Los callbacks pueden registrarse en un Future en cualquier momento. Estas acciones se ejecutan tan pronto como el Future se completa. Una acción registrada en un Future completado se ejecuta inmediatamente. La acción puede ejecutarse en un hilo separado, dependiendo del ExecutorService subyacente. Las acciones registradas en un Future cancelado se ejecutan con el resultado fallido.

El control de validación (Validation) es un funtor aplicativo que facilita la acumulación de errores. Al intentar componer mónadas, el proceso de combinación se detendrá en el primer error encontrado. Sin embargo, Validation continuará procesando las funciones de combinación, acumulando todos los errores. Esto es especialmente útil al validar múltiples campos, como un formulario web, cuando deseas conocer todos los errores encontrados en lugar de uno por uno.

Ejemplo: Obtenemos los campos name y age de un formulario web y queremos crear una instancia válida de Person, o devolver la lista de errores de validación.

Un valor válido está contenido en una instancia de Validation.Valid, mientras que una lista de errores de validación está contenida en una instancia de Validation.Invalid.

El siguiente validador se utiliza para combinar diferentes resultados de validación en una sola instancia de Validation.

Si la validación tiene éxito, es decir, si los datos de entrada son válidos, entonces se crea una instancia de Person con los campos name y age proporcionados.

La List de Vavr es una lista enlazada inmutable. Las mutaciones crean nuevas instancias. La mayoría de las operaciones se realizan en tiempo lineal. Las operaciones consecutivas se ejecutan una por una.

La implementación de io.vavr.collection.Stream es una lista enlazada perezosa (lazy). Los valores se calculan solo cuando se necesitan. Debido a su naturaleza perezosa, la mayoría de las operaciones se realizan en tiempo constante. En general, las operaciones son intermedias y se ejecutan en una sola pasada.

Lo sorprendente de los streams es que podemos usarlos para representar secuencias que son (teóricamente) infinitamente largas.

Leyenda:

Vavr proporciona una API de coincidencia (match) que es similar a la de Scala. Se habilita agregando el siguiente import a nuestra aplicación:

Teniendo los métodos estáticos Match, Case y los patrones atómicos (atomic patterns)

En el alcance, el ejemplo inicial de Scala puede expresarse de esta manera:

⚡ Usamos nombres de métodos en mayúsculas uniformes porque 'case' es una palabra clave en Java. Esto hace que la API sea especial.

En Vavr usamos patrones para definir cómo se deconstruye una instancia de un tipo específico. Estos patrones pueden usarse junto con la API de coincidencia (Match).