¿El remitente de un evento debe ser siempre un Objeto genérico?

8

Al programar eventos en C #, se recomienda que crear un delegado en forma de:

delegate XEventHandler(object sender, XEventArgs e);

Mi pregunta está en el primer argumento del delegado, object sender . ¿Siempre tiene que ser un object genérico? Tener un remitente de tipo object siempre produce un código similar a este.

val = ((ConcreteType)sender).Property;

o, aún más detallado,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

Un argumento en contra de remitentes fuertemente tipados es que otros objetos pueden reenviar el evento sin preocuparse por el tipo. Si bien esto podría tener sentido en entornos de GUI, no estoy seguro de si podría beneficiarse fuera de una GUI.

¿Qué sucede si siempre se conoce la clase del remitente (al menos como una clase abstracta)? Por ejemplo, si estoy implementando un evento ListChanged en una clase List abstracta, y si otras clases lo heredarán (por ejemplo, LinkedList , ArrayList ), ¿está bien definir mi delegado con un remitente del tipo List ?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

O, ¿habría una desventaja de cambiar el object sender convencional a un tipo más específico?

    
pregunta Krumia 28.10.2014 - 10:55

2 respuestas

9

En este punto, es principalmente una convención (bastante fuerte). Es decir, será extraño si escribe una biblioteca que no sigue esa convención.

Las Pautas para el diseño de eventos dicen:

  

DO usa object como el tipo del primer parámetro del controlador de eventos, y llámalo sender .

Sin embargo, puede observar que la guía actual dice que no debe definir su propio delegado personalizado para eventos, sino que puede usar EventHandler<T> , si puede.

En cuanto al diseño, supongo que también promueve la reutilización de los manejadores de eventos, incluso en contextos no previstos originalmente por el diseñador original del evento.

    
respondido por el jhominal 28.10.2014 - 12:26
0

El motivo de la recomendación es que permite cambios futuros que no necesariamente requieren cambios en el código existente, y especialmente en la interfaz pública.

El propio mecanismo de eventos todavía puede usarse para eventos de estilo "VB6", pero tendrá que cambiar todos los consumidores existentes si alguna vez necesita cambiar la firma (o, lo que es peor, crear nuevas versiones de los mismos eventos). Con el enfoque recomendado, siempre que los elementos más nuevos se hereden de los existentes, puede actualizar la firma sin corregir el código existente.

    
respondido por el Mark Hurd 29.10.2014 - 03:11

Lea otras preguntas en las etiquetas