Gestion d'événement optimale en Java

Bonjour,

Pour qu'une gestion d'événement en java soit optimal et rapide par exemple dans une fenêtre fait-il faire :

Code:

---

1 2 3 4

class Fenêtre impements actionListener,keyLestener   // implementation

---

Ou

Code:

---

1 2 3 4 5 6 7 8

class Fenêtre {   }   Class AliActionListener implements ActionListenere {   // implementation

---

em sachant que les événement s'exécute dans EventQueu

Que me conseillez-vous ?

Merci d'avance.

Salutations

Salut,

L'implémentation de l'interface d'écouteur dans une classe ou une autre ne change pas grand chose aux performances (bon, on peut considérer que le nombre d'instances à créer étant différents, il y a une différence, mais bon, une fenêtre ça s'instancie une fois à priori, et puis, vu la lenteur relative de la GUI, même si tu en ouvrais plusieurs, ça ne va pas changer grand chose).

Ça change l'architecture de ton programme, et, surtout la visibilité des méthodes : si tu implémentes ActionListener sur la classe qui étend JFrame, on pourrait invoquer la méthode actionPerformed() dans une classe qui a une référence sur l'instance de JFrame. C'est pourquoi, en général, on implémente le contrôleur (la classe qui, entre autre, centralise les écouteurs) sous forme de classe interne, un troisième cas que tu n'as pas proposé :

Code:

---

1 2 3 4 5 6

public class Fenetre extends JFrame {   private class Controleur implements ActionListener { }   }

---

En plus, cette classe très liée au fonctionnement de ta fenêtre n'est utilisable que dans cette classe. Si tu as du code à partager réutilisable, tu peux créer une abstraction externe qui contient ce code commun, et faire que la classe Controleur étende cette abstraction.

Salut,

Citation:

---

Envoyé par joel.drigo

Ça change l'architecture de ton programme, et, surtout la visibilité des méthodes : si tu implémentes ActionListener sur la classe qui étend JFrame, on pourrait invoquer la méthode actionPerformed() dans une classe qui a une référence sur l'instance de JFrame. C'est pourquoi, en général, on implémente le contrôleur (la classe qui, entre autre, centralise les écouteurs) sous forme de classe interne, un troisième cas que tu n'as pas proposé :

Code:

---

1 2 3 4 5 6

public class Fenetre extends JFrame {   private class Controleur implements ActionListener { }   }

---

En plus, cette classe très liée au fonctionnement de ta fenêtre n'est utilisable que dans cette classe. Si tu as du code à partager réutilisable, tu peux créer une abstraction externe qui contient ce code commun, et faire que la classe Controleur étende cette abstraction.

---

Il ne faut pas oublier non plus les classes anonymes... ou les expressions lambdas avec Java 8 :

Code:

---

1 2 3 4 5 6 7 8 9 10

class MyFrame extends JFrame {   public MyFrame() { JButton button = new JButton("button"); button.addActionListener((event) -> { // code }); add(button); } }

---

Et avec Java 8 on peut aussi utiliser les références de méthodes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class MyFrame extends JFrame {   public MyFrame() { JButton button = new JButton("button"); button.addActionListener(this::onButtonClick); add(button); }   private void onButtonClick(ActionEvent e) { // code } }

---

Seul défaut ce n'est utilisable qu'avec les listeners "mono-méthode" (à moins de créer une interface fille "mono-méthode" et de caster la lambda/référence de méthode).


a++

Je n'ai pas encore le réflexe de parler des solutions Java8 :oops: (Et puis inconsciemment j'évite avec les débutants, parce que ça oblige à aborder des nouveaux éléments de syntaxe). Quant aux classes anonymes, à part dans des cas très limités, je préfère les éviter : ça disperse les traitements, ou alors ça ne consiste à déléguer vers des méthodes. En plus, On se retrouve avec plein de petites classes anonymes, ce qui ne facilite pas la lisibilité du code. En plus, on se retrouve souvent limité si on veut gérer des interactions dans des UI un peu évoluée. Je dirais même qu'avec les lamba-expressions, on ne devrait plus parler de classes anonymes pour gérer des écouteurs d'évènements : dans ce cadre, justement, je trouve que le bénéfice des lambas est de supprimer l'écriture de cette myriade de classes anonymes (même si en coulisse, je suppose que le compilateur gère les lambdas de cette manière).

Citation:

---

Envoyé par joel.drigo

dans ce cadre, justement, je trouve que le bénéfice des lambas est de supprimer l'écriture de cette myriade de classes anonymes (même si en coulisse, je suppose que le compilateur gère les lambdas de cette manière).

---

En fait c'est assez différent.
Contrairement aux classes anonymes, les lambdas ne sont pas convertis en classes à la compilation. Elles crée en fait une méthode private au sein de la classe.
Ce n'est qu'à l'exécution que la classe correspondante est créée à partir de la méthode en question...


a++

Intéressant. Je suis curieux de savoir pourquoi (je vais aller chercher...).

Citation:

---

Envoyé par joel.drigo

Intéressant. Je suis curieux de savoir pourquoi (je vais aller chercher...).

---

Pour ne pas "polluer" le classpath, et ne pas s'enfermer dans une architecture rigide (création d'une classe à la compilation).

Du coup les lambdas sont compilés en une méthode anonyme, et l'invocation dynamique est utilisé à l'exécution pour créer l'objet qui invoquera cette méthode


a++

Citation:

---

Envoyé par adiGuba

Pour ne pas "polluer" le classpath, et ne pas s'enfermer dans une architecture rigide (création d'une classe à la compilation).

---

Merci de la précision.

Bonjour,

Pour info, j'utilise openjdk 7 et eclipse luna car c'est plus facile à voir les code source et la licence est libre..

Je n'ai pas encore aborder java 8

Qu'en pensez-vous ?

Merci pour ces informations

Salutations

Une petite précision cependant pour l'usage des références de méthode. Je les trouve très adaptées aux callbacks mais pas du tout dans la gestion des listeners, principalement car on peut pas désenregistrer un listeneur si on utilise une référence de fonction. L'exemple*que je donne est pour JavaFX mais le problème se pose bien sur a l'identique avec Swing et AWT ou n'importe quelle structure qui utilise le pattern observer.

*Note: ici j'ai parlé de "classe anonyme" mais adiGuba sera sans doute, je pense, bien plus précis sur le pourquoi du fait que les deux références de methodes ne sont pas considérées comme identiques.

Citation:

---

Envoyé par bouye

Une petite précision cependant pour l'usage des références de méthode. Je les trouve très adaptées aux callbacks mais pas du tout dans la gestion des listeners, principalement car on peut pas désenregistrer un listeneur si on utilise une référence de fonction. L'exemple*que je donne est pour JavaFX mais le problème se pose bien sur a l'identique avec Swing et AWT ou n'importe quelle structure qui utilise le pattern observer.

*Note: ici j'ai parlé de "classe anonyme" mais adiGuba sera sans doute, je pense, bien plus précis sur le pourquoi du fait que les deux références de methodes ne sont pas considérées comme identiques.

---

Oui même si les références de méthodes pointent vers la même méthode, il n'est pas garantie que ce soit la même instance qui sont renvoyée.
Du coup il est impératif de conserver la référence de l'instance si on veut la manipuler de nouveau, comme tu l'indiques sur ton blog.


En fait il n'y a aucune garantie que deux références de méthodes, même identique, retourne la même instance.
Déjà d'une part parce que dans ton exemple (this::monEcouteur) la référence est paramétré par this. Du coup l'instance retourné doit forcément varier si "this" varie...
Et pour le même "this" il aurait fallu mettre en place un cache, mais cela aurait pu être couteux (surtout que ce besoin n'est pas forcément souhaitable).


Mais même sans cela, deux références de méthodes situé à deux emplacements différents renverront deux instances différentes, et même deux "classes anonymes" différentes :

Code:

---

1 2 3 4

Callable<Double> c1 = Math::random; Callable<Double> c2 = Math::random; System.out.println(c1 == c2); // false System.out.println(c1.getClass().equals(c2.getClass())); // false

---

Encore une fois il aurait été possible d'éviter cela en mettant en place un cache, mais cela pourrait être "gourmand" alors que cela n'aurait surtout concerné que quelques cas particulier...
Tout cela alors qu'il existe une solution quoi consiste à faire ce que l'on faisait déjà, c'est à dire de conserver la référence de l'instance...




A noter toutefois que si la référence de méthode n'est pas paramétrée, c'est une constante qui retournera toujours la même instance :

Code:

---

1 2 3

public Callable<Double> randomizer() { return Math::random; }

---

Ici la méthode randomizer() retournera toujours la même instance.


a++