Entendiendo operadores reactivos con diagramas de estado
En este artículo les compartiremos cómo entender los flujos y operadores reactivos (paradigma reactivo) con diagramas de estado bajo estándar UML.
Suele existir una curva de aprendizaje alta para cada paradigma de programación que decidamos aprender; desde entender el mundo real con una abstracción hacia los objetos, hasta entender el mundo real bajo una vista funcional.
Si nos adentramos en el paradigma reactivo, viniendo de un mundo orientado a objetos y manejo de datos en crudo, probablemente tengamos un choque mental con esta nueva forma de ver, diseñar e implementar software. Sin embargo existen documentaciones oficiales dentro de cada Framework/library como la de Project Reactor, que nos muestra, entre tanto detalle técnico, algunas pistas abstractas y algunas analogías que convierten el desafío de entender este nuevo paradigma, en un proceso más digerible y progresivo.
La analogía de la cinta de ensamblaje
Project Reactor expone la analogía de la cinta de ensamblaje…
Realizando un ejercicio de deconstrucción sobre el gif anterior para intentar identificar las partes que conforman este sistema, probablemente concluyamos con 3 grandes grupos; el primero son las estaciones o robots que cumplen una tarea en específico, a estos podríamos llamarles operadores; el segundo sería la cinta en sí misma que podríamos llamarle flujo; y por último el componente al cuál realizamos cambios durante cada estación que llamaremos dato.
Estos 3 grandes grupos ya nos dan una base sólida para entender la programación reactiva, incluso si continuamos observando encontraríamos más partes esenciales del paradigma.
Los invito a identificar sobre la librería Project Reactor, ¿qué podría ser el inicio y fin de la cinta de ensamblaje?.
Enfoquemos nuestro análisis en los operadores y el cómo los diagramas de estado nos ayudan a entender un flujo reactivo…
Cada operador agrega comportamiento y envuelve los pasos anteriores en una nueva instancia. Por lo tanto, toda la cadena está vinculada, de modo que los datos se originan en el primero y se mueven hacia abajo en la cadena, transformados por cada eslabón.
Supongamos que tenemos una cinta que permite ensamblar el acorde G#7 (Sol sostenido séptima). Si a nuestra cinta le ingresara el dato G (Sol), podríamos decir que requerimos 2 estaciones u operadores que me permitan construir, inicialmente el G#(Sol sostenido) y por último, el G#7.
Gráficamente quedaría así:
Ahora intentemos diseñar un diagrama para definir el estado del dato en el tiempo:
Podríamos decir que cada operador se convirtió en un estado donde el dato G(sol) sufre una transformación.
Ahora, ¿qué pasa si el acorde que ingresa a nuestra cinta no es un G(sol) sino un B(Si)? Podríamos esperar un resultado como B#7 (Si sostenido séptima). Sin embargo, el acorde B#7 no es un acorde que relativamente exista, ya que la transformación #(sostenido) inmediatamente lo convierte en un C (Do).
Con esto podemos concluir que nuestro sistema necesita un nuevo diseño que permita de alguna manera identificar este caso y reaccionar a él. Para esto podríamos intentar tener una estación nueva en nuestra cinta que permita realizar un filtrado por el acorde B(Si) y convertir el dato B(Si) en C(Do), realizando una transformación/operación específica para este acorde.
Operación filtrado:
Observen que, a pesar de visualizar nuestra cinta con una nueva estación para filtrar, nuestro diagrama de estados nos permite agregar Guard Conditions y representar gráficamente este flujo de transformación solamente agregando [dato != ‘B’].
Operación de mapeo/conversión:
En este caso, agregamos un nuevo estado convirtiendo un acorde B(Si) en C(Do).
Podemos decir que tenemos un sistema que cumple con la nueva necesidad y reacciona a los cambios externos que sean enviados a través de nuestra cinta en forma de dato.
