ma classe souscrit à des évènements dans son constructeur ou quand on appelle des méthodes dessus.
Quand la fonction Dispose de ma classe est appelée, doit-je desouscrire de ces évènements ou est-ce fait automatiquement ?
ma classe souscrit à des évènements dans son constructeur ou quand on appelle des méthodes dessus.
Quand la fonction Dispose de ma classe est appelée, doit-je desouscrire de ces évènements ou est-ce fait automatiquement ?
Il est mieux de se désouscrire.
merci de ta réponse. Je viens d'en discuter avec un collègue ce midi, et effectivement Il n'y a pas de desouscription automatique même quand le souscripteur est disposé. Donc il faut se désabonner explicitement dans le dispose du souscripteur.
En fait il y a plusieurs possiblités.
Prenons deux classes :
Emetteur : qui emet un event
Souscripteur : qui écoute l'event d'Emetteur
1) Si Emetteur est affecté à null, il sera détruit par le GC, le fait que Souscripteur ne se soit pas désinscrit ne change rien à cela. Par conséquent, les inscriptions ne maintiennent pas Emetteur en vie.
Ce scénario suppose bien sur qu'aucun autre objet du domaine ne fait référence a Emetteur.
2) Si Souscripteur est mis a null sans s'etre désinscrit d'Emetteur, il ne sera pas détruit par le GC car Emetteur contiendra une référence vers ce premier (afin de pouvoir appeler sa méthode). Par conséquent, il restera en vie jusqu'a ce qu'Emetteur soit lui aussi mis à null.
Donc ce qui est faux et qui malgré tout pollue les blogs du net, c'est de dire que c'est Emetteur qui devrait faire l'effort de désinscrire tous ses Souscripteurs au moment de sa mort.
Voici donc la principale question à réfléchir pour faire du bon boulot :
Est-il possible que Emetteur survive plus longtemps que Souscripteur?
Si oui, Souscripteur doit obligatoirement etre désinscrit manuellement.
Si non, rien de spécial n'a besoin d'être fait.
Les Emetteurs a risques sont donc ceux qui ont une durée de vie longue, par exemple les objets globaux, les eventHandlers statiques, les Singletons. Par ailleurs, il est inutile d'etre effrayé a l'idée que des références croisées entre l'émetteur et le souscripteur comme on peut en voir dans certains patterns style MVC se maintiennent en vie, le GC est suffisamment intelligent pour tuer deux objets qui se tiendraient en vie mutuellement.
En fait je me trouvais dans le cas 2) où mon émetteur vie plus longtemps que le souscripteur, d'où ma question.
Partager