javascript - rxjava - ¿En qué se diferencia la programación reactiva de la programación dirigida por eventos?

programacion reactiva ventajas y desventajas

Question

Estoy aprendiendo programación reactiva y programación reactiva funcional en JavaScript. Estoy muy confundido.

Wikipedia dice que hay varias formas de escribir código reactivo, como imperativo, OORP y funcional. ¿Quiero saber si el evento controlado es solo otra forma de escribir código reactivo?

¿Cómo se relaciona la programación reactiva con las promesas? Creo que las promesas son una alternativa al infierno impulsado por eventos y devoluciones de llamada.

Answer 1

¿Cómo se relaciona la programación reactiva con las promesas? Creo que la promesa es una alternativa al infierno impulsado por eventos y devoluciones de llamada.

En la práctica, los dos están relacionados, me gusta llamar a Promises un medicamento de puerta de enlace a la programación reactiva funcional.

+----------------------+--------+-------------+
|                      |  Sync  |    Async    |
+----------------------+--------+-------------+
| Single value or null | Option | Promise     |
| Multiple values      | List   | EventStream |
+----------------------+--------+-------------+

Las promesas pueden considerarse como EventStreams con un solo elemento, o puede pensar en EventStreams como múltiples Promesas a lo largo del tiempo.

Las promesas se pueden encadenar, lo que se está acercando a la programación reactiva:

getUser() // return promise
   .then((userId) => {
       return fetch("/users/"+userId)
   })
   .then((user) => {
       alert("Fetched user: " + user.name)
   })

Lo mismo con bacon.js:

const userStream = userIdStream // EventStream of userIds
   .flatMapLatest((userId) => {
       return Bacon.fromPromise(fetch("/users/"+userId))
   })
const userNameStream = userStream.map((user) => user.name)
userNameStream.onValue((user) => {
   alert("Fetched user: " + user.name)
})

Ambos fragmentos de código hacen lo mismo, pero hay una gran diferencia en el pensamiento: con las promesas estás pensando en manejar una sola acción con pasos asíncronos de una manera clara: el pensamiento es imprescindible, estás haciendo las cosas paso a paso. Con FRP, usted dice "se crea una secuencia de nombres de usuario a partir de la corriente de userIds de userIds aplicando estos dos pasos de transformación". Cuando tenga un flujo de nombres de usuario, sin importar de dónde vinieron, y diga "siempre que haya un nuevo nombre de usuario, muéstrelo al usuario".

El estilo de codificación de FRP lo guiará para modelar su problema como un flujo de valores (es decir, valores que cambian con el tiempo) y las relaciones entre estos valores. Si ya conoce Promesas, la curva de aprendizaje inicial será un poco más fácil, pero el beneficio principal se obtiene solo cuando comienza a pensar y modelar el problema de manera diferente; es posible (si no es muy útil) realizar una programación imperativa con las bibliotecas de FRP.

Answer 2

¿En qué se diferencia la programación reactiva de la programación dirigida por eventos?

La programación dirigida por eventos gira en torno a los llamados eventos, que son cosas abstractas que los programas "disparan" cuando ocurre algo. Otros lugares en su código "escuchan" los eventos y responden con lo que deben hacer cuando suceda ese evento. Por ejemplo, un evento podría ser "el usuario presionó este botón" o "la impresora ha terminado de imprimir su documento".

La programación reactiva se ocupa de los datos . En última instancia, este es un caso especial de programación dirigida por eventos. El evento: datos cambiados. El controlador de eventos: cambiar algunos datos más (si corresponde). Este concepto generalmente se aclara cuando se piensa en una hoja de cálculo. Si establece cell1 = cell2 + cell3 esto implícitamente establece dos controladores de eventos en los datos cambiados eventos de cell2 y cell3 para actualizar los datos de cell2 . Los datos de la celda 1 no tienen tal controlador de eventos, porque ninguna celda depende de su valor.

TL; DR;

Wikipedia dice que hay varias formas de escribir código reactivo, como imperativo, OORP y funcional. ¿Quiero saber si el evento controlado es solo otra forma de escribir código reactivo?

La idea de programación dirigida por eventos es ortogonal a la idea de imperativo frente a OO frente a funcional.

• Programación imperitiva : se enfoca en cambiar el estado de su programa para lograr lo que quiere. La mayoría de las computadoras son imperativas (en oposición a la programación declarativa ), mientras que los lenguajes de nivel superior a veces son declarativos. La programación declarativa, por el contrario, trata de escribir un código que especifica QUÉ quieres que haga en lugar de CÓMO quieres que lo haga el código.
• O bject O O riented programación : se ocupa de los llamados objetos, o bolsas de datos con métodos asociados. Se diferencia de la programación funcional porque los métodos pueden acceder a los datos asociados con los objetos.
• Programación funcional : se ocupa de funciones reutilizables, o procedimientos que toman entradas y salidas. Esto difiere de la programación OO porque las funciones tradicionalmente no tienen la capacidad de asociar datos con una función distinta de las entradas y salidas.

Programación dirigida por eventos : estructura su programa para tratar ("manejar") algo más que sucede en su programa (un "evento"). En otras palabras, estructura su código lógicamente como este.

When Event1 happens
    do A and B

When Event2 happens
    do B and C

Pero hay muchas maneras de escribir este código, y de hecho muchas formas de escribir el código imperativamente, muchas formas de escribirlo funcionalmente, etc. Sin embargo, aquí hay algunos ejemplos.

Imperativamente (con un bucle de eventos):

while(true)
    // some other code that you need to do...

    if Event1 then
        do A
        do B
    if Event2 then
        do B
        do C

Objeto orientado (con hilo de fondo):

// event queue
events = new EventQueue()

handler = new EventHandler()
// creates background thread
Thread.DoInBackground(handler.listenForEvents(events))

// ... other code ...

// fire an event!
events.enqueue(new Event1())

// other file
class EventHandler
    Func listenForEvents(events)
        while(true)
            while events.count > 0
                newEvent = event.dequeue()
                this.handleEvent(newEvent)
            Thread.Sleep(Time.Seconds(1))

    Func handleEvent(event)
        if event is Event1
            this.A()
            this.B()
        if event is Event2
            this.B()
            this.C()

    Func A()
        // do stuff
        return

    Func B()
        // do stuff
        return

    Func C()
        // do stuff
        return

Funcional (Con soporte de idiomas para eventos)

on Event(1) do Event1Handler()
on Event(2) do Event2Handler()

Func Event1Handler()
    do A()
    do B()

Func Event2Handler()
    do B()
    do C()

Func A()
    // do stuff
    return

Func B()
    // do stuff
    return

Func C()
    // do stuff
    return

// ... some other code ...

// fire! ... some languages support features like this, and others have
// libraries with APIs that look a lot like this.
fire Event(1)

¿Cómo se relaciona la programación reactiva con las promesas?

Las promesas son una abstracción del flujo de ejecución del programa que se puede resumir de la siguiente manera:

• Asker: Cuando termines de hacer lo que estás haciendo, ¿me devolverías la llamada?
• Respuesta: Claro, lo prometo.

Nada realmente especial aquí, excepto que es otra forma de pensar en el orden en que se ejecuta el código. Por ejemplo, las promesas son útiles cuando haces una llamada a una máquina remota. Con promesas, puede decir "devuélvame la llamada cuando regrese de esta llamada remota". Cualquiera que sea la biblioteca que utilice, promete devolverle la llamada cuando reciba algo de la máquina remota. A menudo, esto es útil porque le permite hacer otra cosa mientras tanto sin esperar a que vuelva la llamada.

Punch line: hay muchos estilos diferentes de código, pero no juegan un papel muy importante en el patrón de programación reactiva y dirigida por eventos. Que yo sepa, puede hacer programación orientada a eventos y / o reactiva en la mayoría de los lenguajes.

Answer 3

La programación reactiva tiene que ver con flujos, podría ser flujos de eventos, o cualquier otra cosa. Es sobre emitir / anunciar estos flujos o suscribir / ver estos flujos o transformaciones de flujo que conducen a algunos eventos. Así que ambos paradigmas de programación están relacionados.

Answer 4

Para mí es como comparar naranjas con manzanas. Intentemos definir de forma sencilla qué es qué y, así, distinguir las cosas:

La programación reactiva es un paradigma de programación que se aplica cuando uno quiere lograr una funcionalidad similar al enlace de datos en bibliotecas como KnockoutJS. También un ejemplo serían las fórmulas de Excel: todas las celdas son como variables en la memoria. Hay aquellos que simplemente contienen algunos datos y aquellos que se calculan a partir de esos datos. Si el primero cambia, también lo hace el segundo. Preste atención a que el paradigma se trata de la implementación de nivel inferior; cuando alguien está hablando de programación reactiva, se refiere a los datos, sus cambios y lo que sucede cuando muta.

Por otro lado, la programación dirigida por eventos tiene que ver con la arquitectura del sistema. De acuerdo con ese paradigma, los eventos y los manejadores de eventos son la base de un sistema y todo está construido sobre y alrededor de ellos. Ejemplos comunes serían UI y multiplexación de servidores web. ¿Sientes cómo todo esto es diferente? El paradigma se aplica en el nivel de todo un sistema o un subsistema.

¿Cómo se relaciona la programación reactiva con las promesas? Creo que las promesas son una alternativa al infierno impulsado por eventos y devoluciones de llamada.

Promise es una herramienta para lograr la concurrencia y el orden específico de ejecución. Se puede utilizar en cualquier paradigma.

En la práctica, los paradigmas sirven para diferentes propósitos y en diferentes niveles. Puede tener un diseño controlado por eventos con algunos bits de código reactivo. Puede tener un sistema distribuido que utiliza patrones de diseño reactivo. Sin embargo, los eventos son, en última instancia, un concepto de nivel superior. Reactivo se trata de datos y su reevaluación, un enfoque para la implementación o su detalle, y los eventos son algo que naturalmente surge de un caso y que impulsa su diseño.