¿Qué tan malo es que para crear un delegado controlador de eventos con el estándar (Obj remitente, EventArgs args) firma?

Question

Yo entiendo los beneficios del uso de la firma MS delegado controlador de eventos estándar, ya que le permite ampliar fácilmente a la información transmitida a través del evento sin romper ninguna de las viejas relaciones que se basan en la antigua firma del delegado.

Lo que me pregunto es, en la práctica con qué frecuencia las personas siguen esta regla? Decir que tengo un evento simple como esto

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

Es un evento simple, y estoy casi seguro de que los únicos argumentos que jamás voy a necesitar saber del evento NameChanged es el objeto cuyo nombre cambiado, el nombre antiguo y el nuevo nombre. Así es que vale la pena para crear una clase separada NameChangedEventArgs, o para eventos simples como esto es aceptable simplemente devolver los argumentos directamente a través de los argumentos de delegado?

Answer 1

Se puede hacer todo el camino equivocado si usted es el único que tiene que tratar con él. Pero no es una mala idea para aprender las normas y se adhieren a ellos de modo que mantenga buenos hábitos cuando se está trabajando en código con otros.

Así que te voy a hacer un trato. Si la promesa de hacerlo de la manera correcta, te voy a dar un fragmento de código que va a hacer que sea mucho menos de un dolor. Sólo hay que poner esto en un archivo .snippet, y poner ese archivo en:

Mis documentos \ Visual Studio 2008 \ \ fragmentos de código de Visual C # \ Mis fragmentos de código \
(O Visual Studio 2005 si es aplicable)

Y aquí está el fragmento; utilizarlo en VS escribiendo ev2Generic y golpear 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

Utilice los delegados genéricos EventHandler<T> para sus eventos y crear un tipo derivado de EventArgs para mantener los datos de eventos. Así, en otras palabras, siempre. Es algo que siempre sabe exactamente cómo funciona cuando se llega a través de ella, ya que nunca ha hecho lo contrario.

Editar:

CA1003: Use instancias de controlador de eventos genéricos
análisis de código CA1009: declare controladores de eventos correctamente

Answer 3

  

En la práctica, ¿con qué frecuencia las personas no [   utilizar EventArgs clases derivadas].

Nunca me he encontrado un momento en que no se han utilizado las clases derivadas EventArgs. Como se dice a sí mismo, que aumenta su capacidad de cambiar su código más tarde. También me gustaría argumentar que la lectura se mejora, ya que es fácil ver que este es un controlador de eventos.

  

¿Vale la pena crear una separada   NameChangedEventArgs clase, o para   eventos simples como este es que   simplemente aceptable para devolver el   argumentos directamente a través de la   argumentos de delegado?

Parece que decir que utilizaría EventArgs para controladores de eventos con más params y no utilizarla para casos como éste. Honestamente, que no es simplemente una opción al programar en C #. La consistencia es una necesidad, especialmente en el mundo de hoy del foro de este tipo, proyectos de código abierto, etc., donde es fácil perderlo. Claro que si usted está programando esta bajo una roca, puede hacer lo que quiera, pero la mayor comunidad de C # se lo agradecerán siguiendo las normas y en especial el uso de la consistencia en su código.