L'exemple de la première section "Comprendre le mécanisme de traitement d'événements JAVA à partir de zéro (1)" est trop simple, si simple que tout le monde a l'impression qu'un tel code est tout simplement inutile. Mais il n’y a aucun moyen, nous devons continuer à écrire ce code inutile, puis passer à l’étape suivante du code vraiment utile.
1 : Un premier aperçu du modèle événementiel
Nous voulons dire que le modèle événementiel est une version améliorée du modèle d'observateur, puis nous il faut parler de la relation correspondante :
L'observateur correspond à l'auditeur (élève)
L'observé correspond à la source de l'événement (enseignant)
La source d'événement génère un événement, et l'événement a une source d'événement, l'auditeur écoute les événements. Les amis qui aiment parler de choses peuvent dire : hé, qu'est-ce qui génère des événements, surveille les événements et que sont exactement les événements ?
Pas de panique, si on parle de choses en code, l'événement est une classe, et la source de l'événement est aussi une classe. Il existe quatre catégories impliquées dans cela : la source de l'événement (c'est-à-dire l'enseignant, c'est-à-dire l'observateur), l'événement (une classe, voir ci-dessous, généralement nous le nommons se terminant par Event ou EventObject), l'interface de l'auditeur, l'auditeur spécifique (c'est-à-dire les étudiants, c'est-à-dire les observateurs).
Comme mentionné dans la première section de notre article précédent, il existe bien sûr des classes de modèles d'événements toutes faites dans le JDK. Autant les consulter une par une.
Tout d'abord, regardez l'auditeur (c'est-à-dire l'étudiant, l'observateur, ne trouvez pas cela ennuyeux, je continue de laisser tomber les parenthèses pour vous le rappeler, c'est pour donner à chacun une impression plus profonde),
package java.util;
/**
* Une interface de balisage que toutes les interfaces d'écoute d'événements doivent étendre.
* @depuis JDK1.1
*/
public interface EventListener {
}
Ça pourrait' Ce n'est pas plus simple, non ? Il n'y a même pas de méthode déclarée, alors à quoi ça sert ? Rappelez-vous le upcasting en mode orienté objet, son sens est donc de dire à tous les appelants que je suis un auditeur.
Regardons l'événement, c'est-à-dire la classe à la fin d'Event ou EventObject, qui contient la méthode getSource, qui renvoie la source de l'événement (c'est-à-dire l'enseignant, l'observateur),
2 : La version modèle événementielle de la mission assignée par l'enseignantpackage java.util;
/**
*
* La classe racine à partir de laquelle tous les objets d'état d'événement doivent être dérivés.
*
* Tous les événements sont construits avec une référence à l'objet, le " source",
* qui est logiquement considéré comme l'objet sur lequel l'événement en question
* s'est produit initialement.
*
* @depuis JDK1.1
*/classe publique EventObject implémente java.io.Seriallessly {
privé statique final long serialVersionUID = 5516075349620653480L;
/**
* L'objet sur lequel l'événement s'est initialement produit.
*/
source d'objet transitoire protégée;/**
*/
* Construit un événement prototypique.
*
* @param source L'objet sur lequel l'événement s'est initialement produit.
* @exception IllegalArgumentException si la source est nulle.
*/
public EventObject (source d'objet) {
if (source == null)
@return L'objet sur lequel l'événement s'est produit initialement.public Object getSource() {
}
return source;}
/**
* L'objet sur lequel l'événement s'est initialement produit.
*
* @return L'objet sur lequel l'événement s'est produit initialement.
*/
public String toString() {
return getClass().getName() + "[source=" + source + "]";>
Ceci Les classes sont également très simples. Si les classes supérieures et les résultats dans le modèle d'observateur ont beaucoup de logique et de méthodes, alors vous ne pouvez presque rien voir dans les classes supérieures et les interfaces. le modèle événementiel. C'est vrai,
Dans le modèle événementiel, les concepteurs de JDK ont réalisé le plus haut niveau d'abstraction, qui consiste à laisser la classe supérieure représenter uniquement : Je suis un événement (contenant la source de l'événement) , ou, je C'est un auditeur !
Anciennes règles, donnons à la classe schéma en premier :
Ensuite, le code l'implémente :
Interface observateur (étudiant). Puisque dans le modèle événementiel, il n'y a qu'une seule interface sans aucune méthode, EventListener, nous pouvons donc d'abord implémenter notre propre interface. Afin d'être cohérent avec le code de l'article précédent, le nom de la méthode que nous avons déclaré dans cette interface est également appelé update. Notez que bien sûr nous ne pouvons pas utiliser ce nom, ni même ajouter d'autres déclarations de méthode, en fonction de nos besoins métiers.
package com.zuikc.events;
import java.util.Observable;
interface publique HomeworkListener étend java.util.EventListener {
Public void update(HomeworkEventObject o, Object arg);
}
Puis implémentez la classe observateur (étudiant), comme suit :
package com.zuikc . événements ;
classe publique Student implémente HomeworkListener{
private String name;
public Student(String name){
this.name = name;
}
@Override
public void update(HomeworkEventObject o, Object arg) {
Teacher professor = o.getTeacher();
System.out.printf("L'étudiant %s a observé (en fait a été informé) que %s lui avait assigné une mission "%s" n", this.name, professor.getName(), arg);
}}
Comparez avec l'article précédent, y a-t-il des changements ?
Implémentez ensuite la sous-classe d'événement, comme suit :
package com.zuikc.events;import java.util .*;enseignant de classe publique {package com.zuikc.events;
classe publique HomeworkEventObject extends java.util.EventObject {
public HomeworkEventObject(Source de l'objet) {
Ensuite, il y a notre classe de professeur, qui est la source de l'événement, comme suit :
super(source);
}
public HomeworkEventObject(Enseignant enseignant) {
super(enseignant);
}
public Enseignant getTeacher ( ){
return (Teacher) super.getSource(); Encapsule la méthode getSource de la classe parent EventObject pour obtenir la source de l'événement. Théoriquement, il nous est également possible d'utiliser la méthode getSource de la classe parent, mais la réencapsuler dans la sous-classe la rendra plus lisible.
nom de chaîne privé;liste privée
/*devoirs; * La classe d'enseignant doit maintenir son propre auditeur (élève) liste, pourquoi ?
* Dans le modèle observateur, l'enseignant est l'observateur, hérité de java.util.Observable, Observable contient cette liste* Maintenant, nous n'avons plus cette liste, nous devons donc en créer une nous-mêmes
this.name = name;
* /
private SethomeworkListenerList;
public String getName() {
return this.name;
}
public Teacher(String name) {this.homeworks = new ArrayList
();
this.homeworkListenerList = new HashSet();
}public void setHomework (String homework) {
listening.update(event, homework);
System.out.printf("%s assigné homework %s n", this.name, homework);
homeworks.add(homework);
HomeworkEventObject event = new HomeworkEventObject( ceci);
pour (écouteur HomeworkListener : homeworkListenerList) {}
>
public void addObserver(HomeworkListener homeworkListener){
homeworkListenerList.add(homeworkListener);
}}
Ce cours est légèrement plus long Donc, un petit peu, il y a quelques endroits à noter :
Le premier endroit est que Teacher n'a pas de classe parent, Teacher, car la source de l'événement Source dans l'événement, est encapsulée dans HomeworkEventObject. Il n'y a rien de mal à cela. Les objets métier sont isolés du code du framework et le découplage est très bon. Cependant, pour cette raison, nous devons maintenir nous-mêmes une liste d'étudiants dans le professeur, nous avons donc vu la variable homeworkListenerList.
Deuxièmement, en mode observateur, nous appelons directement les notifyObservers de Observable pour notifier les observés. Maintenant, nous ne pouvons compter que sur nous-mêmes, nous avons donc vu ce code,
pour (écouteur HomeworkListener : homeworkListenerList) {
listening.update(event, homework);
}
Ce n'est pas du tout un problème. Continuons à regarder le code client :
package com.zuikc.events;
import java.util.EventListener;
public class Client {
public static void main(String[ ] args) {
Étudiant student1= new Student("Zhang San");
Étudiant student2 = new Student("李思");
Teacher professor1 = new Teacher("zuikc");
professor1.addObserver (student1);
professeur1.addObserver(student2);
professeur1.setHomework("Devoirs sur le mécanisme d'événement pour le deuxième jour");
}}
Les résultats sont les suivants :
Du point de vue du client, nous n'avons presque rien changé du tout. C'est exactement le même que le code client dans le fichier. mode observateur, mais en interne Quant au mécanisme d'implémentation, nous utilisons le mécanisme événementiel.
Résumons maintenant les différences entre le modèle observateur et le modèle événementiel :
1 : La source d'événement n'hérite plus d'aucun modèle ni de la classe parent du modèle lui-même, transformant complètement le business Le code est découplé ;
2 : Dans le modèle d'événement, chaque auditeur (observateur) doit implémenter sa propre interface. C'est vrai, regardez nos événements de souris. La sous-table contient des événements de clic, de double-clic, de déplacement, etc., qui augmentent respectivement la flexibilité du code
Dans tous les cas, nous utilisons un tas de ; small Le code blanc implémente un exemple de modèle événementiel Bien qu'il ne soit d'aucune utilité pratique, il explique également le principe. Dans la section suivante, nous examinerons un code légèrement complexe et apparemment utile !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
