UTILISER CORRECTEMENT LES LISTENERS SWING
Utilisateur anonyme
-
15 mars 2013 à 14:37
cs_GodConan Messages postés 2113 Date d'inscription samedi 8 novembre 2003 Statut Contributeur Dernière intervention 6 octobre 2012 - 19 juin 2013 à 06:32
cs_GodConan Messages postés 2113 Date d'inscription samedi 8 novembre 2003 Statut Contributeur Dernière intervention 6 octobre 2012 - 19 juin 2013 à 06:32
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/55013-utiliser-correctement-les-listeners-swing
https://codes-sources.commentcamarche.net/source/55013-utiliser-correctement-les-listeners-swing
19 juin 2013 à 06:32
En effet, c est la méthode utilisé par beaucoup de générateur de code ;o) ( tu peux surement en voir des exemples dans mes derniers sources avec IHM ) je crois que j'utilise NetBeans ;o)
Pour en revenir au listener ;o), j'évite aussi de faire plusieurs instance du même écouteur, dans ton exemple tu le dois à cause des paramètres ;o), ne pourraient il pas être évité d'ailleurs??
Arf!! non ;o) ce ne serait plus le meme exemple ..;o)
Bonne journée
15 mars 2013 à 15:42
A vrai dire, je n'ai pas tellement compris comment tu préconises de les utiliser. Pourrais tu me donner un exemple stp ?
15 mars 2013 à 14:37
Il y a une faute de frappe dans la description ("listenrers" au lieu de "listeners"). De plus, ton utilisation des écouteurs pose problème. Pour éviter qu'il ne garde des références sur des objets dont on voudrait bien se débarrasser et pour rendre le code plus facile à adapter (par exemple par héritage), il est recommandé d'éviter de mettre du code dans ses "callbacks", il est préférable d'appeler simplement une méthode de la classe de l'instance à laquelle on abonne un écouteur. Ainsi, il ne garde qu'une référence implicite sur l'instance en question et rien d'autre, cela réduit les risques de fuite mémoire, cela évite également qu'un objet obsolète soit utilisé si l'instance à laquelle on abonne un écouteur mute (par exemple si l'écouteur reprend la valeur d'un champ de l'objet écouté et qu'elle change). En terme d'évolutivité, si tu souhaites modifier le comportement du code appelé par ton écouteur, tu pourras simplement surcharger la méthode de l'instance alors que si tu mets ce code directement dans une méthode de l'écouteur, tu devras aussi désabonner l'écouteur de l'objet écouté et créer un autre écouteur. Je travaille depuis 2007 et je peux te dire qu'on peut perdre beaucoup de temps bêtement à cause de ce genre de choses. Tu peux prendre exemple sur le code généré par Matisse GUI Builder dans Netbeans, il crée des méthodes privées pour chaque méthode implémentant l'interface d'un écouteur. C'est après avoir perdu un temps fou à corriger des fuites mémoire que j'ai fini par comprendre pourquoi il procède ainsi. En fait, je conseille d'utiliser les écouteurs comme de vulgaires pointeurs sur fonctions, ça évite beaucoup d'ennuis.