Discussion :

[Battant]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
class Fenêtre impements actionListener,keyLestener
 
// implementation

Ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[joel.drigo]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[adiGuba]

Salut,

Ç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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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++

[joel.drigo]

Je n'ai pas encore le réflexe de parler des solutions Java8 (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).

[adiGuba]

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++

[joel.drigo]

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