¿Los eventos solo se usan para la programación GUI?

¿Los eventos solo se usan para la programación GUI?

¿Cómo se maneja en la programación de backend normal cuando algo le sucede a esta otra cosa?

No. Son realmente útiles para implementar Observadores y asegurarse de que las clases estén cerradas a modificaciones.

Digamos que tenemos un método que registra nuevos usuarios.

public void Register(user) {
    db.Save(user);
}

Entonces alguien decide que se debe enviar un correo electrónico. Podríamos hacer esto:

public void Register(user) {
    db.Save(user);
    emailClient.Send(new RegistrationEmail(user));
}

Pero acabamos de modificar una clase que se supone que está cerrada a modificaciones. Probablemente esté bien para este pseudocódigo simple, pero probablemente sea el camino a la locura en el código de producción. ¿Cuánto tiempo hasta que este método tenga 30 líneas de código apenas relacionadas con el propósito original de crear un nuevo usuario?

Es mucho más agradable dejar que la clase realice su funcionalidad principal y generar un evento que indique a quien esté escuchando que un usuario estaba registrado, y pueden tomar cualquier acción que necesiten tomar (como enviar un correo electrónico).

public void Register(user) {
    db.Save(user);

    RaiseUserRegisteredEvent(user);
}

Esto mantiene nuestro código limpio y flexible. Una de las piezas de OOP que a menudo se pasan por alto es que las clases se envían mensajes entre ellas. Los eventos son estos mensajes.

No.

Un ejemplo clásico de los eventos que se utilizan en la lógica sin GUI son los desencadenantes de la base de datos.

Los disparadores son códigos que se ejecutan cuando ocurre un evento determinado (INSERT, DELETE, etc.). Me parece un evento.

Esta es la definición de evento de Wikipedia:

En informática, un evento es una acción o suceso reconocido por el software que puede ser manejado por el software. Los eventos de la computadora pueden ser generados o activados por el sistema, por el usuario o de otras maneras. Típicamente, los eventos se manejan sincrónicamente con el flujo del programa, es decir, el software puede tener uno o más lugares dedicados donde se manejan los eventos, con frecuencia un bucle de eventos. Una fuente de eventos incluye al usuario, que puede interactuar con el software mediante, por ejemplo, pulsaciones de teclas en el teclado. Otra fuente es un dispositivo de hardware como un temporizador. El software también puede activar su propio conjunto de eventos en el bucle de eventos, por ejemplo, para comunicar la finalización de una tarea. Se dice que el software que cambia su comportamiento en respuesta a eventos es impulsado por eventos, a menudo con el objetivo de ser interactivo.

No todos los eventos son generados por el usuario. Algunos son generados por un temporizador como un crontab de una base de datos INSERT como mencioné anteriormente.

La definición también establece que algunos programas o sistemas están "impulsados ​​por eventos, a menudo con el objetivo de ser interactivos" , de los cuales se puede deducir que el propósito o la utilidad de los eventos no son únicamente, sino más bien a menudo, para proporcionar interactividad (como las GUI) aunque no necesariamente GUI, ya que los programas CLI también pueden ser interactivos).

La programación basada en eventos también se usa para la programación de servidores de alto rendimiento.

En una carga de trabajo de servidor típica, la mayor parte del tiempo que procesa un resultado proviene de E / S. Por ejemplo, extraer datos de una unidad de disco duro (7200 RPM) puede demorar hasta 8,3 ms. Para un procesador moderno de GHz, eso equivaldría a ~ 1 millón de ciclos de reloj. Si una CPU esperara los datos cada vez (sin hacer nada), perderíamos MUCHOS ciclos de reloj.

Las técnicas de programación tradicionales evitan esto mediante la introducción de múltiples hilos . La CPU intenta ejecutar cientos de subprocesos al mismo tiempo. Sin embargo, el problema que plantea este modelo es que, cada vez que una CPU cambia de hilo, requiere cientos de ciclos de reloj para cambiar de contexto . Un cambio de contexto es cuando la CPU copia la memoria local del hilo en los registros de la CPU y también almacena el registro / estado del hilo viejo en la RAM.

Además, cada subproceso debe utilizar una cierta cantidad de memoria para almacenar su estado.

Hoy, ha habido un impulso para los servidores que tiene un solo hilo, que se ejecuta en un bucle. Luego, las piezas de trabajo se envían a una bomba de mensajes , que actúa como una cola para el hilo único (al igual que en un hilo de la interfaz de usuario). En lugar de esperar a que termine el trabajo, la CPU establece un evento de devolución de llamada para cosas como el acceso al disco duro. Lo que reduce el cambio de contexto.

El mejor ejemplo de tal servidor es Node.js , que se ha demostrado que es capaz de manejar 1 millón de conexiones simultáneas con hardware modesto, mientras que un servidor Java / Tomcat tendría dificultades en unos pocos miles.

Los eventos también se usan mucho en la programación de red (por ejemplo, Nginx) para evitar costosos bucles de espera ocupada y, en cambio, proporcionan una interfaz limpia para saber exactamente cuándo está disponible una determinada operación (E / S, datos urgentes, etc.). Esta también es una solución al problema de C10k .

La idea básica es proporcionar al sistema operativo un conjunto de sockets (es decir, conexiones de red) para monitorear eventos, todos ellos o solo algunos que le interesen particularmente (datos disponibles para leer, por ejemplo); cuando el sistema operativo detecte dicha actividad en uno de los sockets de la lista, recibirá una notificación del evento que estaba buscando por la API, que luego tendrá que determinar de dónde proviene y actuar en consecuencia .

Ahora, esta es una vista de bajo nivel y abstracta, además difícil de escalar. Sin embargo, hay muchos frameworks de nivel superior que se ocupan de eso de manera incluso multiplataforma: Twisted para Python, Boost.Asio para C ++ o liberant para C me vienen a la mente.

Los sistemas integrados casi siempre son inherentemente impulsados ​​por eventos, incluso si no están programados explícitamente como tales.

Estos eventos provienen de cosas como interrupciones de hardware, pulsaciones de botones, lecturas de período de analógico a digital, vencimientos de temporizadores, etc.

Los sistemas integrados de baja potencia tienen aún más probabilidades de estar controlados por eventos; pasan la mayor parte del tiempo durmiendo (CPU durmiendo en un modo de bajo consumo), esperando que algo suceda (ese "algo" es un evento).

Uno de los marcos más comunes y populares para sistemas integrados controlados por eventos es la Plataforma Cuántica (QP) (el QP también funciona bajo Linux, Windows y cualquier sistema operativo similar a Unix). Las máquinas de estado son un ajuste natural para la programación basada en eventos, como el programa no es "secuencial" en el sentido típico, más bien, es un conjunto de "devoluciones de llamada" que se invocan según el estado del sistema y el evento actual.

Mensajes del evento Gregor Hohpe.

Arquitecturas dirigidas por eventos Gregor Hohpe.

Arquitectura SEDA , Gales, Culler, Cervecero.

¿Cómo se maneja en la programación de backend normal cuando sucede algo?

La máquina de estados finitos es un enfoque común

Given(State.A)
When(Event.B)
Then(State.C)
    .and(Consequences.D)

En los sistemas integrados, los eventos ocurren durante las interrupciones. Hay muchas fuentes de interrupciones, desde temporizadores hasta E / S.

Además, RTOS también puede tener eventos. Un ejemplo es esperar un mensaje de otra tarea.

Para el sistema no incorporado, pero algo que estaba haciendo en C # era el sistema SCADA. Hubo muchos eventos vinculados a lo que estaba sucediendo en el almacén cuando la carga se descargó parte del evento generado por el sistema y otra parte estaba escribiendo un nuevo estado en la base de datos. Por supuesto, teníamos un cliente GUI, pero era solo para mostrar el estado de la base de datos que reflejaba el estado del almacén. Por lo tanto, era un software de servidor de fondo basado en eventos y subprocesos. Bastante desafiante de desarrollar.

https://en.wikipedia.org/wiki/SCADA