Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?
Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 0.
Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.