Les événements sont-ils uniquement utilisés pour la programmation GUI?
Les événements sont-ils uniquement utilisés pour la programmation GUI?
Comment gérez-vous dans la programmation backend normale quand quelque chose arrive à cette autre chose?
Nan. Ils sont vraiment pratiques pour implémenter Observers et s'assurer que les classes sont fermées à la modification.
Disons que nous avons une méthode qui enregistre les 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 qui est censée être fermée à toute modification. Probablement bien pour ce pseudo-code simple, mais probablement le chemin de la folie dans le code de production. Combien de temps jusqu'à ce que cette méthode soit 30 lignes de code qui sont à peine liées à l'objectif initial de créer un nouvel utilisateur ??
Il est beaucoup plus agréable de laisser la classe exécuter ses fonctionnalités de base et de déclencher un événement indiquant à quiconque écoute qu'un utilisateur a été enregistré, et ils peuvent prendre toutes les mesures nécessaires (comme envoyer un e-mail).
public void Register(user) {
db.Save(user);
RaiseUserRegisteredEvent(user);
}
Cela maintient notre code propre et flexible. L'un des éléments souvent négligés de OOP est que les classes s'envoient messages. Les événements sont ces messages.
Nan.
Un exemple classique d'événements utilisés dans une logique non graphique est les déclencheurs de base de données.
Les déclencheurs sont du code qui est exécuté lorsqu'un événement donné se produit (INSERT, DELETE, etc.). Cela me semble être un événement.
Voici la définition de Wikipédia de l'événement:
En informatique, un événement est une action ou une occurrence reconnue par un logiciel qui peut être gérée 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 par d'autres moyens. En règle générale, les événements sont gérés de manière synchrone avec le flux du programme, 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 comprend l'utilisateur, qui peut interagir avec le logiciel au moyen, par exemple, de touches sur le 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 ex. pour communiquer l'achèvement d'une tâche. Un logiciel qui change son comportement en réponse à des événements est dit piloté par les événements, souvent dans le but d'être interactif.
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 ou par une base de données INSERT comme je l'ai mentionné précédemment.
La définition indique également que certains programmes ou systèmes sont "pilotés par les événements, souvent dans le but d'être interactifs", dont on peut déduire que le but ou l'utilité des événements ne sont pas seulement, mais plutôt souvent , pour fournir l'interactivité (comme les interfaces graphiques, mais pas nécessairement les interfaces graphiques, car les programmes CLI peuvent également être interactifs).
La programmation basée sur les événements est également utilisée pour la programmation de serveurs hautement performants.
Avec une charge de travail de serveur typique, la plupart du temps, le traitement d'un résultat provient en réalité d'E/S. Par exemple, l'extraction de données d'un disque dur (7200 tr/min) peut prendre jusqu'à 8,3 ms. Pour un processeur GHz moderne, cela équivaudrait à environ 1 million de cycles d'horloge. Si un CPU devait attendre les données à chaque fois (ne rien faire), nous perdrions BEAUCOUP de cycles d'horloge.
Les techniques de programmation traditionnelles contournent cela en introduisant plusieurs threads . Le processeur essaie d'exécuter simultanément des centaines de threads. Cependant, le problème que ce modèle est que, chaque fois qu'un CPU change de thread, il nécessite des centaines de cycles d'horloge pour changement de contexte . Un changement de contexte est lorsque le CPU copie la mémoire locale du thread dans les registres du CP et stocke également l'ancien registre/état du 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 un Push pour les serveurs qui a un seul thread, qui tourne en boucle. Ensuite, les morceaux de travail sont poussés sur un pompe de message , qui agit comme une file d'attente pour le thread unique (un peu comme sur un thread d'interface utilisateur). Au lieu d'attendre la fin du travail, le CPU définit un événement de rappel, pour des choses comme l'accès au disque dur. Ce qui réduit le changement de contexte.
Le meilleur exemple d'un tel serveur est Node.js , qui s'est révélé capable de gérer 1 million de connexions simultanées avec un matériel modeste, tandis qu'un serveur Java/ Tomcat le ferait lutte à quelques milliers.
Les événements sont également largement utilisés dans la programmation réseau (par exemple Nginx) pour éviter les boucles coûteuses en attente et fournir à la place une interface propre pour savoir exactement quand une certaine opération 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 seulement certains 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 recevrez une notification de l'événement que vous recherchiez par l'API, que vous devrez ensuite trier d'où il vient et agir en conséquence .
Maintenant, c'est une vue de bas niveau et abstraite, de plus difficile à bien mettre à l'échelle. Cependant, il existe de nombreux cadres de niveau supérieur qui traitent cela de manière homogène sur plusieurs plates-formes: 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 événementiels, même s'ils ne sont pas programmés explicitement comme tels.
Ces événements proviennent de choses comme les interruptions matérielles, les pressions de bouton, les lectures analogiques-numériques périodiques, les expirations de temporisation, etc.
Les systèmes embarqués de faible puissance sont encore plus susceptibles d'être déclenchés par les événements; ils passent la plupart de leur temps à dormir (le processeur dort en mode basse consommation), en attendant que quelque chose se passe (ce "quelque chose" est un événement).
L'un des cadres les plus courants et les plus populaires pour les systèmes embarqués événementiels est le Quantum Platform (QP) (le QP fonctionne également sous Linux, Windows et tout système d'exploitation de type Unix.) Les machines à états sont un élément naturel adapté à la programmation événementielle, car le programme n'est pas "séquentiel" au sens typique, mais plutôt un ensemble de "rappels" qui sont invoqué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?
Finite State Machine est une approche courante
Given(State.A)
When(Event.B)
Then(State.C)
.and(Consequences.D)
Pour les systèmes non intégrés, mais quelque chose que je faisais en C # était le système SCADA. Il y avait de nombreux événements liés à ce qui se passait dans l'entrepôt lorsque le chargement était déchargé une partie de l'événement généré par le système et une autre partie écrivait un nouvel état dans la base de données. Nous avions bien sûr un client GUI mais c'était juste pour montrer l'état de la base de données qui reflétait l'état de l'entrepôt. Il s'agissait donc d'un logiciel de serveur principal basé sur des événements et des threads. Assez difficile à développer.
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, RTOS peut également avoir des événements. Un exemple attend un message d'une autre tâche.