Quelle est la différence entre les écouteurs et gestionnaires d'événements en Java?
En termes généraux de Java, il y a des écouteurs et des gestionnaires d'événements.
Je veux dire que je les utilise sans le savoir, selon ce qui est disponible dans l’API.
Ma question est la suivante: dans quels cas utilisons-nous des écouteurs et dans quels cas utilisons-nous des gestionnaires pour les événements?
Quelle est la différence entre eux? Les caractéristiques??
J'ai cherché des raisons et je n'ai pas trouvé d'explication valable pour Java.
Il n'y a pas de différence formellement définie entre les auditeurs et les gestionnaires. Certaines personnes diront probablement qu'elles sont interchangeables. Pour moi cependant, ils ont un sens légèrement différent.
Un écouteur est un objet qui s'abonne aux événements d'une source. Cf. le motif observateur . En règle générale, vous pouvez avoir plusieurs auditeurs qui s'abonnent pour chaque type d'événement. Ils sont ajoutés à addXyzListener.
Exemple: Le MouseListener dans l'API Java.
Un gestionnaire est un objet responsable du traitement de certains événements. Un scénario typique serait de fournir un gestionnaire pour un événement/tâche spécifique en tant qu'argument d'un constructeur, ou set le gestionnaire via une méthode setXyzHandler. En d'autres termes, vous avez généralement un gestionnaire pour chaque type d'événement.
Exemple: Le MemoryHandler dans l'API Java.
La différence la plus fondamentale est l'association
- Le récepteur est associé à Source de l'événement (Ex: clavier)
- Le gestionnaire est associé à un événement Event (Ex: keydown)
D'une manière générale, il n'y aura qu'un seul gestionnaire de gestionnaire central qui gérera tous les événements, tandis que dans le cas d'un auditeur, chaque entité qui souhaite écouter doit gérer sa propre collection d'écouteurs.
Voici comment je vois les choses:
A auditeur veille à ce qu'un événement soit déclenché. Par exemple, une KeyListener attend KeyEvents, une MessageListener attend que des messages arrivent dans une file d'attente, etc.
Le handler est responsable du traitement de l'événement. Normalement, les auditeurs et les manipulateurs vont de pair. Par exemple, KeyListener indique à ExitHandler que "la lettre Q a été appuyée" et le gestionnaire exécute une logique telle que le nettoyage des ressources et la sortie de l'application en douceur. De manière similaire, ButtonClickListener indiquerait au même ExitHandler que le "bouton Exit a été cliqué". Donc, dans ce cas, vous avez deux événements différents, deux auditeurs différents mais un seul gestionnaire.
Un écouteur écoute les événements qui sont des objets de valeur de données décrivant un événement. Lorsque l'événement s'est produit et que l'ordre des événements est souvent important. Appuyer sur la touche '0' suivi de '1' est différent de '1' et '0'.
Un gestionnaire, gère un objet complexe, par ex. une nouvelle connexion Socket. Le gestionnaire peut traiter l'objet pour n'importe quelle durée. Le temps de création et de commande des objets n’est pas si important. Une connexion de client0 ou client1 peut se produire dans n'importe quel ordre.
Je pense que la différence est subtile car un écouteur concret est aussi un gestionnaire d'événements ou a au moins une méthode qui peut être considérée comme un gestionnaire d'événements ..__ C'est-à-dire qu'un écouteur concret gère ou gère la réaction à l'événement après réception un objet événement (de la source de l'événement) avec toutes les informations utiles sur l'événement qui vient de se produire (sur la source de l'événement) . Comme ce listener doit implémenter une interface xxxListener qui l'oblige à implémenter au moins une méthode qui est à son tour exécuté par l'objet source d'événement lorsque l'événement se produit, de sorte que le programme d'écoute lui-même peut être considéré comme un gestionnaire et, plus précisément, la méthode de l'interface de programme d'écoute implémentée par l'objet Listener peut être considérée comme le gestionnaire d'événement réel .Alors, je considère le gestionnaire d'événements comme étant simplement le code exécuté en réaction à un événement . Ceci est différent d'un objet Listener qui est un élément d'un concept plus abstrait tel qu'un modèle de conception Observer . Ceci est ma vision personnelle du sujet.
À mon sens, la différence la plus importante est le fait que nous utilisons des écouteurs par source d'événement, contrairement au gestionnaire, qui est par type d'événement.
Un écouteur est un objet qui est notifié lorsqu'un événement se produit et qui a 2 exigences principales : 1-il doit avoir été enregistré avec une ou plusieurs sources pour recevoir des notifications sur des types d'événements spécifiques .__-2. implémente des méthodes pour recevoir et traiter ces notifications . Le gestionnaire est responsable du traitement des événements.
Ils sont conceptuellement la même chose - un objet qui exécute une action en réponse à un événement d'interface utilisateur. Généralement, dans Swing, ces objets sont appelés "gestionnaires" au niveau de l'aspect et de la convivialité (pour la gestion d'événements de widget de bas niveau) et "écouteurs" au niveau plus abstrait de l'interface utilisateur (où vous allez implémenter votre logique d'application). ).
EventHandler est introduit dans JavaFX pour tous les contrôles de l'interface utilisateur. Alors que l'auditeur est emprunté pour les observables, tels que les propriétés.
EventHandler est un moyen de distinguer les événements observables des événements ui.
J'ai essayé de donner un sens à toutes les informations et je suis perdu. J'ai regardé Delphi (Pascal), C, C++, Java ... rien n'est clair.Alors, après un mois, c'est le problème tel que je le vois. Je suis peut-être totalement en retard, alors dites-moi poliment, s'il vous plaît.
Un expéditeur d'événement, un récupérateur tant que l'expéditeur enregistre le récupérateur. J'ai 4 boîtes de dialogue qui doivent être mises à jour chaque fois qu'un fichier (dont le code de traitement est dans un autre module que les 4 boîtes de dialogue) change. J'ai envisagé de mettre à jour chacune d'elles à l'ancienne, mais j'ai ensuite examiné les événements Delphi et la gestion des messages. Voyons voir:
Le fichier F (The Sender) a fini de lire et doit informer Dialogs 1..4 du fait qu’il a maintenant des données à afficher et à l’utilisateur avec lequel jouer. Quel est le meilleur?
Essayez d'enregistrer Dialogs 1..4 en tant qu'écouteurs et que l'expéditeur déclenche en quelque sorte un OnUpdatedDataEvent?
Essayez d’envoyer un message à travers le système, en espérant que Dialogs 1..4 l’attrapera?
Notez que l’événement garde les éléments couplés alors que la messagerie ne le fait pas ... et est une tâche difficile à déboguer.
Et je me demande comment le bloc de code Fichier pourra enregistrer 4 écouteurs (les boîtes de dialogue)?
Ce que je recherche, c’est la possibilité d’appeler en cascade, c’est-à-dire que l’appelant appelle un auditeur, celui qui appelle l’autre ... jusqu’à ce qu’il atteigne la fin de la chaîne. Je me demande même si c'est même possible.
Un exemple:
Say File F est une liste de langues. Maintenant, DialogBox 1 fait quelque chose à la liste (ajoute une nouvelle langue par exemple); cette liste déroulante met à jour le fichier F; cela déclenche à son tour un DataUpdatedEvent. les 4 boîtes de dialogue contiennent, par exemple, des TComboBox qui affichent la liste des langues lorsqu'elles apparaissent. Je souhaite que les 4 boîtiers remarquent le changement et mettent à jour le contenu de leur propre combo avec le fichier fraîchement mis à jour ... sans avoir à s'inquiéter de savoir comment les combos savent qu'ils doivent actualiser leur contenu. Si cela fonctionne comme prévu, le paramètre Sender sera transféré et la boîte de dialogue qui a déclenché le dataUpdateEvent sera ignorée car elle sera déjà mise à jour. Après tout, un if sender = self puis continuer au gestionnaire d’événements suivant devrait être facile à implémenter.
Tout cela parce que je veux exercer mon cerveau ... pour prévenir la maladie d'Alzheimer, ajoute-t-il avec beaucoup de succès.