Différence entre les gestionnaires d'événements et les rappels
Quelle est la différence entre un gestionnaire d'événements et une fonction de rappel?
D'une manière générale, un "rappel" est sous le contrôle du processus de détection. Vous dites donc à un gestionnaire d'interface graphique "appeler myaction lorsque ce bouton est enfoncé" et le gestionnaire d'interface graphique appelle l'action lorsque le bouton est enfoncé.
Les gestionnaires d'événements, d'autre part, fonctionnent à une étape supprimée. Le gestionnaire de l'interface graphique est configuré pour envoyer des messages à un gestionnaire d'événements. Vous dites à un gestionnaire d'événements que les poussées de bouton sont gérées par le programme myaction. Lorsque le bouton est enfoncé, le gestionnaire de l'interface graphique place un message dans la file d'attente du gestionnaire d'événements et continue la gestion de l'interface graphique. Le gestionnaire d'événements récupère le message dans la file d'attente, voit qu'il s'agit d'un bouton Pousser, lance le programme myaction et passe à la gestion de l'événement suivant. Habituellement, le programme myaction s'exécutera en tant que thread indépendant ou même en tant que processus distinct.
Bien que le modèle de "gestionnaire d'événements" soit plus complexe, il est beaucoup plus robuste et moins susceptible de se bloquer lorsqu'une action échoue. Cela permet également une interface graphique plus réactive.
Un rappel est une procédure que vous passez comme argument à une autre procédure. La procédure recevant le paramètre peut l'appeler ou la partager afin que d'autres procédures du système puissent l'appeler.
Un gestionnaire d'événements est une procédure appelée lorsqu'un événement se produit. Cela peut être un rappel.
Un gestionnaire d'événements est un type de rappel. Il est appelé chaque fois qu'un événement se produit. Le terme est généralement utilisé en termes d'interfaces utilisateur où les événements sont des choses comme déplacer la souris, cliquer sur quelque chose, etc.
Cette question est très ancienne mais j'ai trouvé ce lien depuis MSDN très intéressant. J'espère que quiconque trébuchera sur cette question tirera quelque chose de ce lien.
Rappel (de Wikipedia): "code exécutable qui est passé en argument à un autre code".
Gestionnaire d'événements (à nouveau de Wikipedia): "sous-programme de rappel asynchrone qui gère les entrées reçues dans un programme".
Ce qui se trouve être la façon dont je l'ai toujours compris: un gestionnaire d'événements est un type de rappel très spécifique.
Événements - Pensez à un serveur (employé) et un client (patron). Un employé peut avoir plusieurs patrons. L'employé déclenche l'événement à la fin de la tâche et les patrons peuvent décider d'écouter l'événement employé ou non. L'employé est l'éditeur et les patrons sont abonnés.
Rappel - Le patron a spécifiquement demandé à l'employé de faire une tâche et à la fin de la tâche terminée, le patron veut être informé. L'employé s'assurera que lorsque la tâche est terminée, il ne notifie que le patron qui a demandé, pas nécessairement tous les patrons. L'employé n'informera pas le patron si le travail partiel est effectué. Ce ne sera que lorsque toute la tâche sera terminée. Un seul patron a demandé les informations et l'employé n'a posté la réponse qu'à un seul patron.
Un autre aspect de cela est que les événements décrivent quelque chose qui s'est passé dans le passé, alors qu'un rappel est souvent utilisé pendant que quelque chose se passe.
Lorsqu'un événement se déclenche, on vous dit que quelque chose s'est produit. Lorsqu'un rappel est utilisé, on vous demande de participer à quelque chose.
Une bibliothèque ou un framework peut émettre des événements qui vous indiquent que quelque chose s'est produit. Un cadre vous offre des points auxquels vous pouvez brancher du code (peut-être en tant que rappels) afin que vous puissiez participer activement à un processus.
Une partie du problème est que l'événement, le rappel se réfèrent aux mécanismes techniques ainsi qu'à des processus plus abstraits.
La réponse de James Anderson est la plus détaillée. Développant sa réponse; Le rappel fait référence à tout code transmis en tant qu'argument à une méthode, destiné à être appelé ultérieurement de manière asynchrone. Cependant, un rappel ne définit pas comment le processus de rappel lui-même doit être implémenté. C'est là que commence la classification des rappels. Traditionnellement, un processus de rappel ressemblerait à:
- le développeur définit un rappel et le transmet à une fonction définie par la bibliothèque (qui sait quoi faire avec le rappel pour que le processus appelant ou le processus de détection puisse l'appeler), par exemple dans le noeud,
var server = require('http').createServer(function(req, res){/* your code */});
createServer est la fonction définie par la bibliothèque qui s'assure que le processus de détection arrive à appeler le rappel approprié, qui dans ce cas est function(req, res){/* your code */}
- pendant l'exécution, le processus de détection reçoit l'emplacement direct du rappel (car la fonction définie par la bibliothèque l'a fait pour vous) et l'appelle. Cela signifierait 2 choses:
- les développeurs de la bibliothèque devraient toujours savoir comment gérer les différents processus de détection car chacun peut avoir une façon différente de rappeler
- et si le rappel doit être appelé plusieurs fois, il peut charger le processus de détection. Par exemple si le processus de détection est un processus GUI, vous souhaiterez que le thread GUI s'exécute avec autant de tâches que possible, pour une expérience GUI fluide.
D'où la nécessité de mettre en place un mécanisme de rappel, qui a résolu ces 2 problèmes:
- un processus externe qui définirait un point simultané pour que la fonction de bibliothèque enregistre les rappels et que le processus de détection notifie quand ces rappels enregistrés doivent être appelés.
- Cela signifiait que les développeurs de ces deux processus peuvent désormais travailler indépendamment l'un de l'autre, sans vraiment se connaître.
- Ce processus externe est devenu connu sous le nom de boucle d'événement (dans le nœud, par exemple). Le terme "événement" est simplement le processus de notification de la boucle d'événements par le processus de détection et le rappel enregistré est devenu le gestionnaire d'événements.
- le processus externe (ou la boucle d'événements) a mis les événements en file d'attente et les a exécutés, supprimant ainsi la charge du processus de détection qui pouvait désormais reprendre ce qu'il faisait le mieux.
Ainsi, pour les événements qui se sont produits plusieurs fois, la boucle d'événements ou les gestionnaires d'événements sont devenus le moyen d'implémentation des rappels, alors que les rappels d'origine sont toujours préférés pour les événements ponctuels car vous ne chargez pas vraiment le processus de détection et n'avez pas besoin d'avoir la boucle d'événement pour un seul événement car ce n'est pas efficace.
- Le code du nœud js ci-dessus est un événement unique (car la connexion au serveur pour un client est un événement unique alors qu'il peut y avoir de nombreuses réponses qui sont implémentées en tant que gestionnaires d'événements) et est un exemple de rappel simple.
J'adore la façon dont toutes ces réponses diffèrent les unes des autres.
J'en conclurais que, d'un point de vue terminologique, les événements et les rappels sont interchangeables. Ce qu'ils signifient dans un langage ou un cadre de programmation spécifique et diffèrent cependant, car toute plate-forme a tendance à choisir ses termes préférés.
Les mécanismes sous-jacents sont similaires, mais la sémantique est différente. Les rappels et les gestionnaires d'événements sont appelés de manière asynchrone.
La fonction de rappel est généralement passée explicitement à partir d'une routine d'appelant pour demander des informations. Les informations sont renvoyées quelque temps plus tard, transmises en tant qu'arguments au rappel par l'appelé. À ce moment, la routine d'appel termine son activité. Souvent, le rappel est une fermeture - syntaxiquement à l'intérieur de la routine d'appel, et souvent sans nom (anonyme). Cela pourrait ressembler un peu à ce qui suit, en javascript:
function caller() {
someLibrary.getMeSomething(arg1, arg2, function(returnedData) {
// this is the callback which will do something with returnedData
});
}
Ainsi, l'appelé (someLibrary.getMeSomething) reçoit une fonction de rappel anonyme, et quelque temps plus tard, cette fonction est appelée avec le returnData. Un rappel est comme un événement à un coup sur un seul récepteur.
Les gestionnaires d'événements sont également "rappelés", mais ils sont généralement utilisés sur une longue période pour plusieurs événements, comme les clics de souris, les événements de réseau, etc. De plus, plusieurs objets peuvent être intéressés par le même événement. Pour ces raisons, vous vous abonnez ou vous enregistrez généralement aux événements dans le code de configuration (comme l'initialisation d'objet) et le gestionnaire d'événements est plus généralement une méthode nommée. Habituellement aussi, chaque type d'événement est identifié comme une constante ou une chaîne.
Donc, en Python cela pourrait ressembler à:
class MyUIClass:
def __init__(self):
someUILib.register(someUILib.events.MOUSE_CLICK, self.my_mouse_click_handler);
def my_mouse_click_handler(self, eventInfo):
# do something with event
if eventInfo.x < 100:
print 'You clicked in the margin'
Un rappel est une fonction (méthode) que vous passez en argument à une autre fonction (méthode). La fonction (méthode) recevant le paramètre peut l'appeler ou la partager afin qu'une autre fonction (méthode) du système puisse l'appeler.
Un gestionnaire d'événements est une fonction (méthode) appelée lorsqu'un événement se produit. Cela peut être un rappel.