parámetro de evento; "remitente como Objeto", o "remitente como T"?

Question

Cuando escribo eventos públicos para mis objetos comerciales, he adaptado el hábito de siempre pasar la instancia como "emisor como Objeto", además de parámetros específicos adicionales. Me acabo de preguntar ahora ¿por qué no estoy especificando la clase?

Así que para usted con más experiencia; ¿Alguna vez aprobó la clase distinta como remitente en un evento? Y si es así, ¿cuáles son sus criterios de decisión para cuando esto está bien/no está bien?

Answer 1

No seas extremo. EventHandler(object sender, EventArgs e) tiene un remitente de objeto para que podamos usarlo en muchas circunstancias. Pero eso no significa que un emisor fuertemente tipado sea malo. Un remitente fuertemente tipado es útil cuando este delegado no va a ser ampliamente utilizado (como EventHandler) p.

public delegate void SaveHandler(Controller sender, EventArgs e); 

Ahora otros desarrolladores (o alguien que use su biblioteca) pueden recogonize que el remitente tienen que ser un Controller, y ellos estarán contentos de no codificar así:

public void MySaveHandler(object sender, EventArgs arg) 
{ 
    var controller = sender as Controller; 
    if (controller != null) 
    { 
     //do something 
    } 
    else 
    { 
     //throw an exception at runtime? 
     //It can be avoided if sender is strongly-typed 
    } 
} 

Y usted incluso puede hacerlo genérico:

public delegate void SaveHandler<T>(T sender, EventArgs args) 
               where T: IController; 

Es puramente legal y buena práctica en C#. Debe aclarar lo que quiere hacer y luego elegir la mejor manera. Cualquiera de ellos es malo/malo.

Answer 2

No hay tal restricción. Es solo una guía que se sigue a lo largo de BCL (Base Class Library) y otros marcos populares.

Le recomendaría que lo siga para mantener la coherencia si va a ser utilizado por otros desarrolladores o se lanzará como un marco.

Answer 3

Hay un design guideline que especifica que un controlador de eventos debe tener dos params: remitente (un Objeto) y e (EventArgs o derivado de eso).

Answer 4

Por lo que yo veo, puede crear delegados con los parámetros que desee y luego crear un evento utilizando ese delegado y luego puede invocar el evento y pasar los parámetros o puede usar el argumento de evento personalizado como se muestra here . Como la otra respuesta sugiere. Mantenlo constante.

en realidad no responde a su pregunta acerca de los criterios de decisión, pero creo que sirve

Answer 5

Mi filosofía actual es mantener las prácticas de código lo más cerca posible de la manera estándar de Microsoft como sea posible. Usted consigue dos cosas de esto:

• nuevos desarrolladores pueden entender rápidamente su código
• se entrena a los desarrolladores existentes cómo el resto del marco funciona

Answer 6

no es un obligatorio para que usted pueda tener tal implementación. Normalmente se realiza debido a que el delegado EventHandler se diseñó con dicho prototipo.

Es un simple guideline seguido a través de la Biblioteca de clases base. Pero seguro que puedes hacerte tus propios Parámetros e implementaciones.

Pero recuerde que si va a ser utilizado por algún desarrollador que no sea usted, deberá conocer dicha implementación. Su don para el bien común y la flexibilidad de utilizar un evento en cualquier lugar independientemente de la clase de su utiliza en.

Si se define una personalizada Prototipo para el evento entonces yo sugeriría que también se define personalizada Delegado que se asegurará de que se tener una excepción si no se pasa el tipo apropiado.(Usuario tendrá que hacer una conversión explícita si es necesario)

De esta manera:

public delegate void MyEventHandler(MyType sender, EventArgs e); 

luego usarlo cuando sea necesario como:

this.MyEvent += new MyEventHandler(my_eventhandlerfunction); 

Answer 7

Es una buena práctica usar la firma object sender, EventArgs e, como el método puede manejar cualquier evento de esa firma. Por ejemplo, en un proyecto que utiliza un control de gráficos, existen varios tipos de eventos MouseOver, de un DataSeries, de la Leyenda, de todo el lienzo.

De esta manera, puede manejar cualquier fuente del evento, ya que la mayoría de las veces, la información está en el EventArgs.

Además, no tiene que enviar el remitente al pasarlo al delegado, ya que cualquier instancia de clase es un objeto en el fondo.

Answer 8

Hubo mucha discusión sobre una pregunta relacionada en StackOverflow hace algún tiempo. Aquí está la pregunta: Event Signature in .NET -- Using a strong-typed sender

Finalmente, todo se reduce a la preferencia. En la mayoría de los casos, le gustaría que los manejadores de su evento estén vinculados a un tipo de clase particular, por lo que hacer que el remitente sea un objeto y luego regresar a la clase para obtener acceso a sus propiedades puede no ir bien con usted [ tampoco me cae bien].

Además, con .NET 3+ y la introducción de la covarianza y la contravarianza del delegado, no debería ser un problema utilizar un delegado fuertemente tipado. Debo admitir que he usado manipuladores de eventos fuertemente tipados más de una vez en mi código.

Como dije antes, se trata de preferencia; Microsoft acaba de emitir un conjunto de guía líneas no reglas ...