Événement explicite ajouter/supprimer, mal compris?

J'ai été à la recherche en gestion de la mémoire de beaucoup récemment et ont été à la recherche à la façon dont les événements sont gérés, maintenant, je vois explicite ajout/suppression de syntaxe pour l'inscription à l'événement.

Je pense que c'est assez simple, ajouter/supprimer juste me permet d'effectuer une autre logique quand je s'abonner et se désabonner? Suis-je le faire, ou est-il de plus?

Aussi, alors je suis ici, des conseils et des pratiques exemplaires pour le nettoyage de ma événement poignées.

OriginalL'auteur Hammerstein | 2010-05-27

  1. 3

    Ajouter/supprimer syntaxe est couramment utilisé pour "avancer" un événement de mise en œuvre à une autre classe.

    Nettoyage des abonnements (pas de l'événement "poignées") est mieux fait par la mise en œuvre de IDisposable.

    Mise à JOUR: Il y a une certaine variation sur l'objet qui doit mettre en œuvre IDisposable. Le Rx de l'équipe fait les meilleures décisions à partir d'une conception de point de vue: les abonnements sont eux-mêmes IDisposable. Régulière .NET les événements n'ont pas un objet qui représente l'abonnement, donc le choix est entre l'éditeur (la classe à laquelle l'événement est défini) et l'abonné (généralement de la classe qui contient la fonction de membre d'être abonné). Alors que ma conception des instincts préférez faire l'abonné IDisposable, la plupart du monde réel code de l'éditeur IDisposable: c'est une facilité de mise en œuvre, et il peut y avoir des cas où il n'y a pas une réelle instance de l'abonné.

    (Qui est, si le code nettoie cas d'abonnement à tous. La plupart de code qui ne fonctionne pas.)

    Ha, je me réfère à eux comme des abonnements lorsque l'on parle à mes collègues encore le moment je poste une question, je suis en utilisant le mauvais terminologie. Merci pour la clarification.

    OriginalL'auteur Stephen Cleary

  2. 12

    Ajouter/supprimer des propriétés sont essentiellement de la même logique d'utilisation/propriétés avec les autres membres.
    Il vous permet de créer une certaine logique supplémentaire lors de l'inscription à un événement, et encapsule l'événement lui-même.

    Un bon exemple de POURQUOI vous voulez le faire, c'est arrêter de supplémentaires de calcul quand il n'est pas nécessaire (personne n'est à l'écoute de l'événement).

    Par exemple, permet de dire que les événements sont déclenchés par un timer, et nous ne voulons pas la minuterie de travail si vous n'êtes pas inscrits à l'événement:

    private System.Windows.Forms.Timer timer = new System.Windows.Forms.Timer();
private EventHandler _explicitEvent;
public event EventHandler ExplicitEvent 
{
   add 
   { 
       if (_explicitEvent == null) timer.Start();
       _explicitEvent += value; 
   } 
   remove 
   { 
      _explicitEvent -= value; 
      if (_explicitEvent == null) timer.Stop();
   }
}

    Vous auriez probablement souhaitez verrouiller la ajouter/supprimer un objet (un coup)...

    OriginalL'auteur Yochai Timmer

  3. 6

    Oui, l'ajout/suppression de syntaxe vous permet de mettre en place votre propre abonnement logique. Lorsque vous quittez (la notation standard pour un événement), le compilateur génère mise en œuvre standard. C'est comme l'auto-propriétés.

    Dans l'exemple suivant, il n'y a pas de réelle différence entre Event1 et Événement2.

    public class Foo  
{ 
  private EventHandler handler; 
  public event EventHandler Event1 
  { 
    add { handler += value; } 
    remove { handler -= value; } 
  } 

  public event EventHandler Event2;  
}

    Mais c'est un sujet distinct de "nettoyage" des gestionnaires. C'est l'abonnement de la classe qui devrait faire de vous désabonner. La publication de classe ne peut pas aider avec cela très bien.

    Imaginez une classe qui serait "propre" de l'abonnement de la liste de ses événements. Il ne peut raisonnablement le faire quand il est Disposé lui-même, et il est peu probable d'être productif comme un Aliéné classe devient perceptible peu de temps après, il est Éliminé.

    Je crois que l'utilisateur final ne pouvait pas le faire: Foo foo = ...; foo.Event1(sender, e); mais pourrait faire foo.Event2(null, null);.
    Merci pour l'exemple et de clarification. Je pensais que je l'avais, mais j'étais sur la pensée! Je vais poster ma question sur la gestion de la mémoire dans une autre question, comme je pense qu'il est plus que je veux poser.
    Je ne me trompe, vous recevez un message d'erreur dans les deux cas, mais vous recevez un autre dans le second cas, error CS0070: The event 'Program.Foo.Event2' can only appear on the left hand side of += or -= (except when used from within the type 'Program.Foo').
    Oui, il y a des différences, mais seulement observable à partir de l'intérieur de Foo.

    OriginalL'auteur Henk Holterman