17 votes

Comment fonctionnent les événements faibles ?

Je suis en train d'apprendre WPF et je suis tombé sur le concept des événements faibles, mais j'ai vraiment du mal à le comprendre. J'ai lu d'innombrables articles sur Stackoverflow et regardé des exemples de code, mais je n'arrive pas à comprendre.

Voici mon dilemme :

  1. Je comprends que lorsqu'un objet s'abonne à un événement, la source de l'événement doit détenir une référence à l'abonné.
  2. Je comprends également que si l'abonné sort du champ d'application ou est explicitement détruit mais que la source d'événement n'est pas détruite, l'abonné ne sera pas ramassé car la source d'événement conserve une référence à l'abonné.
  3. Une méthode courante pour éviter cela consiste à désabonner explicitement l'abonné de la source avant la destruction de l'objet. Je comprends que cela peut poser un problème si le programmeur n'est pas en mesure de déterminer quand cela se produira.

Donc, à partir de ce qui précède, je comprends comment l'utilisation d'événements peut provoquer des fuites de mémoire et pourquoi il est nécessaire d'utiliser un modèle de référence faible, mais ce qui m'empêche de comprendre, c'est comment le modèle d'événement faible atteint réellement cet objectif ? Que fait-il différemment ?

Il est certain que même s'il existe une classe qui gère les événements, elle doit toujours abonner et désabonner les gestionnaires à la source, d'où l'existence de références, ce qui pose les mêmes problèmes que la manière standard d'utiliser les événements.

Quelqu'un pourrait-il m'expliquer quel concept fondamental me manque ou m'échappe et m'aider à "comprendre" le modèle d'événement faible ?

18voto

Chris Shain Points 33569

Ce que vous ne comprenez pas, c'est que les événements faibles (qui utilisent les services de Références faibles sous les couvertures, qui à leur tour utilisent un GCHandle ) tirent parti du comportement intégré du CLR dans le cas particulier où il est nécessaire d'accéder à un objet sans détenir une référence forte à celui-ci, c'est-à-dire qu'ils ne sont pas contraints par les "règles" normales auxquelles votre code d'application est soumis.

Voir http://sankarsan.wordpress.com/2008/08/09/weak-references/

Dans les coulisses, le WeakEventManager détient une référence faible à l'abonné de l'événement. Si l'abonné se trouve être GC'd avant que l'événement ne soit levé, le WeakEventManager se contente de hausser les épaules et de dire "OK, ce type est mort, je vais juste arrêter d'essayer de le notifier de cet événement à partir de maintenant".

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X