Discussion :

[le y@m's]

Bonjour,

Je viens d'écrire un petit article qui présente la classe EventHandler permettant de simplifier l'écriture de listeners.
Simplifier l'écriture des listeners avec EventHandler.

Bonne lecture.

le y@m's

[Gueritarish]

Merci pour cet article le y@m's

[deathness]

Il y a là un avantage esthétique évident, mais j'avoue que je préfère personnellement éviter de telles surcouches juste pour cette raison.

En effet si le code est destiné a être maintenu par d'autre, j'ai personnellement eu la douleur d'avoir à gérer/comprendre de nombreuses surcouches "inutiles".

[Robin56]

Comme il a été mentionné en introduction, la raison n'est pas que purement esthétique.

[le y@m's]

Il y a là un avantage esthétique évident, mais j'avoue que je préfère personnellement éviter de telles surcouches juste pour cette raison.

En effet si le code est destiné a être maintenu par d'autre, j'ai personnellement eu la douleur d'avoir à gérer/comprendre de nombreuses surcouches "inutiles".

En plus de la lisibilité (qui est bien plus que de l'esthétique, surtout quand on maintient du code), la création des listeners avec la classe EventHandler permet aussi de réduire l'empreinte disque et mémoire de son application (particulièrement avec les grandes applications).

J'ai moi aussi fait beaucoup de maintenance de code et la lisibilé, avec la documentation, est un critère primordial. En fait je dirais que le cas de la maintenance de code est le meilleur argument pour l'utilisation de l'EventHandler.

Tu parles de la douleur de maintenir du code avec beaucoup de couches inutiles, ce que je comprends, mais là la "surcouche" est très faible. On est loin d'un gros framework nécessitant plusieurs heures d'apprentissage, c'est une simple classe standard de type factory appréhendable en 5 min grace à notre amie la javadoc.
Le gain de lisibilité (déjà maintenu des classes de plusieurs milliers de lignes avec plusieurs dizaines de classes anonymes, c'est assez douloureux aussi ) est quand même très largement supérieur au "coût" .

[Uther]

A noter qu'avec java 8 ça sera faisable bien plus proprement et efficacement grâce aux références de méthode.

Pour reprendre un exemple du tuto:

Code :

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

1
2
3
4
5
6
7
button.addActionListener(new ActionListener() {
 
    @Override
    public void actionPerformed(ActionEvent e) {
       helloworld.sayHello();
    }
});

Deviendra :

Code :

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

button.addActionListener(helloworld::sayHello);

[hwoarang]

Merci pour l'article, ca peut etre interessant. Concernant la lisibilité, je pense qu'il suffit de regarder le code pour comprendre comment ca marche. Quoique en lisant l'article, le passage de parametres ne me parait pas tres intuitif. Ceci dit, ca rend le code plus concis, ce qui est bien.
En revanche, on parle d'empreinte mémoire mais on parle bien du jar généré, non ? Si oui, il faudrait voir l'efficacité à l'execution et l'impact sur la consommation de mémoire. C'est efficace à ce niveau la ?

A noter qu'avec java 8 ça sera faisable bien plus proprement et efficacement grâce aux références de méthode.

Ca commence a ressembler à du C++/Csharp. Bref, ce qui voulait etre évité lors de la création du langage, ca, non ?