Quelle erreur est-il pour créer un délégué de gestionnaire d'événements avec la signature standard (expéditeur Obj, EventArgs args)?

Question

Je comprends les avantages de l'utilisation du gestionnaire d'événements standard MS signature de délégué car il vous permet de développer facilement sur les informations transmises par l'événement à briser les vieilles relations qui sont basées sur la signature de l'ancien délégué.

Ce que je me demande est en pratique à quelle fréquence les gens suivent cette règle? Dire que j'ai un simple événement comme celui-ci

public event NameChangedHandler NameChanged;
public delegate void NameChangedHandler(Object sender, string oldName, string newName);

Il est un événement simple, et je suis presque positif que les seuls arguments que je vais jamais besoin de savoir de l'événement NameChanged est l'objet dont le nom changé, l'ancien nom et le nouveau nom. Est-il donc la peine de créer une classe NameChangedEventArgs séparée, ou pour des événements simples comme celui-ci est-il acceptable pour revenir juste les arguments directement par les arguments des délégués?

Answer 1

Vous pouvez faire quoi que ce soit dans le mauvais sens si vous êtes le seul qui doit faire face. Mais ce n'est pas une mauvaise idée d'apprendre les normes et les respecter afin que vous garder de bonnes habitudes lorsque vous travaillez sur le code avec d'autres.

Je vais vous faire une affaire. Si vous promets de le faire de la bonne façon, je vais vous donner un extrait de code qui va faire beaucoup moins d'une douleur. Il suffit de mettre cela dans un fichier .snippet, et de mettre ce fichier dans:

Mes documents \ Visual Studio 2008 \ Code Snippets \ Visual C # \ My Code Snippets \
(Ou Visual Studio 2005 le cas échéant)

Et voici l'extrait; l'utiliser dans VS en tapant ev2Generic et en appuyant sur Tab:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Generic event with two types/arguments.</Title>
      <Shortcut>ev2Generic</Shortcut>
      <Description>Code snippet for event handler and On method</Description>
      <Author>Kyralessa</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>type1</ID>
          <ToolTip>Type of the first property in the EventArgs subclass.</ToolTip>
          <Default>propertyType1</Default>
        </Literal>
        <Literal>
          <ID>arg1Name</ID>
          <ToolTip>Name of the first argument in the EventArgs subclass constructor.</ToolTip>
          <Default>property1Name</Default>
        </Literal>
        <Literal>
          <ID>property1Name</ID>
          <ToolTip>Name of the first property in the EventArgs subclass.</ToolTip>
          <Default>Property1Name</Default>
        </Literal>
        <Literal>
          <ID>type2</ID>
          <ToolTip>Type of the second property in the EventArgs subclass.</ToolTip>
          <Default>propertyType2</Default>
        </Literal>
        <Literal>
          <ID>arg2Name</ID>
          <ToolTip>Name of the second argument in the EventArgs subclass constructor.</ToolTip>
          <Default>property2Name</Default>
        </Literal>
        <Literal>
          <ID>property2Name</ID>
          <ToolTip>Name of the second property in the EventArgs subclass.</ToolTip>
          <Default>Property2Name</Default>
        </Literal>
        <Literal>
          <ID>eventName</ID>
          <ToolTip>Name of the event</ToolTip>
          <Default>NameOfEvent</Default>
        </Literal>
      </Declarations>
      <Code Language="CSharp">
        <![CDATA[public class $eventName$EventArgs : System.EventArgs
      {
        public $eventName$EventArgs($type1$ $arg1Name$, $type2$ $arg2Name$)
        {
          this.$property1Name$ = $arg1Name$;
          this.$property2Name$ = $arg2Name$;
        }

        public $type1$ $property1Name$ { get; private set; }
        public $type2$ $property2Name$ { get; private set; }
      }

      public event EventHandler<$eventName$EventArgs> $eventName$;
            protected virtual void On$eventName$($eventName$EventArgs e)
            {
                var handler = $eventName$;
                if (handler != null)
                    handler(this, e);
            }]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Answer 2

Utilisez les délégués génériques EventHandler<T> pour vos événements et créer un type dérivé de EventArgs pour tenir vos données d'événement. En d'autres termes, toujours. Il est quelque chose que vous savez toujours exactement comment cela fonctionne quand vous tombez sur elle parce qu'elle n'a jamais fait autrement.

Edit:

Analyse du code CA1003: Utilisez les instances de gestionnaire d'événement générique
Analyse du code CA1009: DECLARE gestionnaires d'événement correctement

Answer 3

  

Dans la pratique comment faire souvent les gens [non   utiliser EventArgs classes dérivées].

Je ne l'ai jamais rencontré un moment où les classes dérivées EventArgs ont pas été utilisés. Comme vous le dites vous-même, il augmente votre capacité à changer votre code plus tard. Je dirais aussi que la lisibilité est améliorée, car il est facile de voir que c'est un gestionnaire d'événements.

  

Est-il utile de créer un séparé   classe NameChangedEventArgs, ou pour   des événements simples comme celui-ci est-il   acceptable pour retourner seulement la   arguments directement à travers le   arguments des délégués?

Vous semblez dire que vous utiliseriez EventArgs pour les gestionnaires d'événements avec plus params et ne pas utiliser pour des cas comme celui-ci. Honnêtement, c'est tout simplement pas une option lors de la programmation en C #. La cohérence est un must, surtout dans le monde d'aujourd'hui du forum comme celui-ci, les projets open source, etc où il est facile de le perdre. Bien sûr, si vous programmez cela sous un rocher, vous pouvez faire ce que vous voulez, mais la plus grande communauté C # vous remerciera pour le respect des normes et en particulier en utilisant la cohérence dans votre code.