Forma preferida de declarar eventos

13

Estoy bastante contento con mi comprensión del modelo de eventos .NET. Creo que podría estar malinterpretando un pequeño matiz del sistema.

Cuando empecé a poner eventos en mis clases, usaría la forma estándar así:

public event EventHandler<MyEventArgs> MyEvent;

Esto significaba que cualquier cosa que se suscribiera al evento necesitaría un método como:

void HandleThatEvent(object sender, MyEventArgs args){...}

Lo que está bien, pero descubrí que rara vez me importaría el remitente, por lo que se hincharon muchas firmas de métodos.

Así que cambié a declarar mis propios tipos de delegado

public delegate void MyEventHandler(SomeClass argument);

Lo que redujo el desorden, pero me dejó con un pequeño problema a la hora de escribir controladores:

eventImplmentor.MyEvent += HandleThatEvent;
.
.
.
void HandleThatEvent(/*oh, um, what arguments does it take? Intellisense isn't telling me*/)

Así que tendría que volver a la declaración del delegado y mirar y luego volver y escribirlas, o compilarlas y esperar a que me avisen.

Así que ahora, en lugar de eso, solo estoy usando Action , Action<T> o cualquier ajuste de plantilla.

public event Action<SomeClass> MyEvent;

Para poder desplazarme sobre el evento y que me digan qué parámetros espera.

Mi pregunta, después de todo eso: ¿Existe una mejor práctica para declarar eventos en C #? ¿Debo volver a la forma EventHandler<T> , o es aceptable Action<T> ?

    
pregunta Matt Ellen 13.04.2011 - 12:16

1 respuesta

7

Para el manejo simple de eventos internos, existen aquellos que simplemente usan Action o Action<T> , como está proponiendo. Tiendo a usar el patrón estándar, incluido el Remitente, incluso para eventos internos, porque nunca se sabe cuándo querrá exponer una clase o evento, y no querría la pena de tener que refactorizar el método del evento solo para hacer Es público.

Estoy de acuerdo con usted en que la firma de manejo de eventos es un poco más pesada de lo que debería ser en escenarios simples, pero está bien diseñada para manejar la migración incremental ya que los argumentos de eventos adicionales pueden llegar a ser necesarios con el tiempo. En general, mantendría el patrón estándar, especialmente porque, como se ha señalado, solo obtienes el soporte adecuado de IntelliSense si lo haces.

Por lo que vale la pena, dedico algo de tiempo a esto y se me ocurrió un patrón de manejo de eventos diferente: Firma del evento en .NET - ¿Utilizando un 'Sender' con letra fuerte? . El objetivo aquí no era eliminar el remitente, sino hacerlo genéricamente sólido tipado como TSender en lugar de débilmente tipado como System.Object . Funciona muy bien; sin embargo, uno pierde el soporte de IntelliSense cuando hace esto, por lo que hay un inconveniente desafortunado.

En general, mantendría el patrón estándar, pero es interesante pensar en formas potencialmente mejores de hacer esto.

    
respondido por el Mike Rosenblum 13.04.2011 - 12:44

Lea otras preguntas en las etiquetas