Les événements sont-ils utilisés uniquement pour la programmation graphique?

Les événements sont-ils utilisés uniquement pour la programmation graphique?

Comment gérez-vous dans la programmation backend normale quand quelque chose arrive à cet autre chose?

Nan. Ils sont vraiment pratiques pour implémenter des observateurs et s’assurer que les classes sont fermées à la modification.

Disons que nous avons une méthode qui enregistre de nouveaux utilisateurs.

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

Ensuite, quelqu'un décide qu'un e-mail doit être envoyé. Nous pourrions faire ceci:

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

Mais nous venons de modifier une classe censée être fermée à la modification. Probablement bien pour ce pseudo-code simple, mais probablement le chemin de la folie dans le code de production. Combien de temps a-t-il fallu jusqu'à 30 lignes de code pour que cette méthode soit à peine liée à l'objectif initial de création d'un nouvel utilisateur?

Il est bien plus agréable de laisser la classe utiliser ses fonctionnalités essentielles et de créer un événement indiquant à tous les utilisateurs qui sont à l'écoute qu'un utilisateur était enregistré et qu'ils peuvent prendre les mesures nécessaires (telles que l'envoi d'un courrier électronique).

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

    RaiseUserRegisteredEvent(user);
}

Cela garde notre code propre et flexible. L'un des aspects souvent négligés de la programmation orientée objet est que les classes s'envoient des messages . Les événements sont ces messages.

Nan.

Un exemple classique d'événements utilisés dans une logique non graphique est la base de données.

Les déclencheurs sont un code qui est exécuté lorsqu'un événement donné se produit (INSERT, DELETE, etc.). Cela ressemble à un événement pour moi.

Ceci est la définition de l'événement par Wikipedia:

En informatique, un événement est une action ou un événement reconnu par un logiciel qui peut être traité par le logiciel. Les événements informatiques peuvent être générés ou déclenchés par le système, par l'utilisateur ou d'une autre manière. En règle générale, les événements sont gérés de manière synchrone avec le flux de programmes, c’est-à-dire que le logiciel peut avoir un ou plusieurs emplacements dédiés où les événements sont gérés, souvent une boucle d’événements. Une source d’événements inclut l’utilisateur, qui peut interagir avec le logiciel, par exemple en appuyant sur les touches du clavier. Une autre source est un périphérique matériel tel qu'une minuterie. Le logiciel peut également déclencher son propre ensemble d’événements dans la boucle d’événements, par exemple pour communiquer l’achèvement d’une tâche. Les logiciels qui changent de comportement en réponse à des événements sont dits événementiels, souvent dans le but d'être interactifs.

Tous les événements ne sont pas générés par l'utilisateur. Certains sont générés par une minuterie, comme une crontab, par une base de données INSERT, comme je l’ai déjà mentionné.

La définition indique également que certains programmes ou systèmes sont "pilotés par les événements, souvent dans un but d'interaction" , d'où l'on peut déduire que le but ou l'utilité des événements ne sont pas uniquement, mais souvent, de fournir une interactivité (comme des interfaces graphiques). mais pas nécessairement les interfaces graphiques, car les programmes CLI peuvent aussi être interactifs).

La programmation par événement est en fait également utilisée pour une programmation serveur hautement performante.

Avec une charge de travail typique du serveur, une grande partie du temps nécessaire pour traiter un résultat provient en réalité des E / S. Par exemple, l'extraction de données d'un disque dur (7 200 tr / min) peut prendre jusqu'à 8,3 ms. Pour un processeur GHz moderne, cela équivaudrait à environ 1 million de cycles d'horloge. Si un processeur attendait les données à chaque fois (sans rien faire), nous perdrions BEAUCOUP de cycles d'horloge.

Les techniques de programmation traditionnelles résolvent ce problème en introduisant plusieurs threads . Le processeur essaie d'exécuter des centaines de threads simultanément. Cependant, le problème de ce modèle est que, chaque fois qu’un processeur change de thread, il faut des centaines de cycles d’horloge pour changer de contexte . Un changement de contexte survient lorsque la CPU copie la mémoire locale du thread dans les registres de la CPU et stocke également le registre / l'état de l'ancien thread dans la RAM.

De plus, chaque thread doit utiliser une certaine quantité de mémoire pour stocker son état.

Aujourd'hui, il y a eu une poussée pour les serveurs qui ont un seul thread, qui tourne en boucle. Ensuite, des tâches sont placées sur une pompe de messages , qui agit comme une file d'attente pour un seul thread (un peu comme sur un thread d'interface utilisateur). Au lieu d'attendre la fin du travail, la CPU définit un événement de rappel, par exemple pour accéder à un disque dur. Ce qui réduit le changement de contexte.

Le meilleur exemple d'un tel serveur est Node.js , qui a démontré sa capacité à gérer 1 million de connexions simultanées avec un matériel modeste, alors qu'un serveur Java / Tomcat aurait du mal à atteindre quelques milliers de personnes.

Les événements sont également très utilisés dans la programmation réseau (par exemple Nginx) pour éviter les boucles d’attente coûteuses et fournir une interface propre pour savoir exactement quand une opération donnée est disponible (E / S, données urgentes, etc.). C'est aussi une solution au problème C10k .

L'idée de base est de fournir au système d'exploitation un ensemble de sockets (c'est-à-dire des connexions réseau) pour surveiller les événements, tous ou tout simplement ceux qui vous intéressent particulièrement (données disponibles pour la lecture, par exemple); lorsqu'une telle activité est détectée par le système d'exploitation sur l'un des sockets de la liste, vous recevez une notification de l'événement que vous recherchiez par l'API, que vous devrez ensuite classer d'où elle vient et agir en conséquence. .

À présent, il s’agit d’une vue abstraite de bas niveau, qui est en outre difficile à mettre à l’échelle. Cependant, de nombreux frameworks de niveau supérieur traitent de cela de manière multiplateforme même: Twisted pour Python, Boost.Asio pour C ++ ou libevent pour C me viennent à l’esprit.

Les systèmes embarqués sont presque toujours intrinsèquement pilotés par les événements, même s'ils ne sont pas programmés explicitement comme tels.

Ces événements proviennent d'éléments tels que des interruptions matérielles, des appuis sur des boutons, des lectures périodiques analogiques / numériques, des expirations de minuterie, etc.

Les systèmes embarqués à faible puissance sont encore plus susceptibles d'être pilotés par les événements; ils passent la majeure partie de leur temps à dormir (le processeur en mode de veille), dans l’attente d’un événement (ce "quelque chose" est un événement).

La plate-forme QP (Quantum Platform) est l’un des frameworks les plus répandus et les plus populaires pour les systèmes embarqués pilotés par les événements. comme le programme n'est pas "séquentiel" au sens classique, il s'agit plutôt d'un ensemble de "rappels" qui sont appelés en fonction de l'état du système et de l'événement en cours.

Messages d'événement Gregor Hohpe.

Architectures pilotées par les événements Gregor Hohpe.

Architecture SEDA , Gallois, Culler, Brasseur.

comment gérez-vous dans la programmation backend normale quand quelque chose se passe faire cette autre chose?

La machine à états finis est une approche commune

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

Dans les systèmes embarqués, les événements se produisent pendant les interruptions. Il existe de nombreuses sources d'interruptions, des minuteries aux E / S.

En outre, le RTOS peut aussi avoir des événements. Un exemple est en attente d'un message d'une autre tâche.

Pour un système non intégré, mais quelque chose que je faisais en C # était un système SCADA. De nombreux événements liés à ce qui se passait dans l'entrepôt lorsque la charge était déchargée faisaient partie de l'événement généré par le système et que l'autre partie écrivait un nouvel état dans la base de données. Nous avions bien sûr un client graphique, mais c'était juste pour montrer l'état de la base de données qui reflétait l'état de l'entrepôt. C'était donc un logiciel serveur basé sur les événements et les threads. Assez difficile à développer.

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