c# - intelecto - ¿Por qué el EventHandler genérico<TArgs> está infrautilizado?

infrautilizado sinonimos

Question

.NET 2.0 agregó el tipo de delegado genérico EventHandler<TArgs> para simplificar el proceso de escribir eventos personalizados; en lugar de tener que definir una clase EventArgs y su delegado correspondiente (por ejemplo, MyEventArgs y MyEventHandler ), solo necesita escribir la clase args.

Teniendo esto en cuenta, ¿por qué este tipo de delegado aparece casi en ninguna parte en .NET Framework? Sé que la mayoría de las API centrales se desarrollaron antes de que se introdujeran los genéricos, pero incluso en partes nuevas del marco como WPF, han optado por definir explícitamente los tipos de delegados; por ejemplo, RoutedEventHandler lugar de EventHandler<RoutedEventArgs> .

¿Hay algo intrínsecamente incorrecto con el delegado controlador de eventos genéricos? A menudo lo uso y me preocupa que mi código aparezca muy fuera de lugar en comparación con las clases integradas.

Answer 1

Lo siguiente es solo mi opinión personal, pero parece (obviamente) razonable para mí; Si observamos de cerca cómo trabajas usando .net y v studio, parece que la notación de tipo genérico parece tener alguna "belleza".

List<string> lst = new List<string>();
lst.Add("hello world");

Si bien el código anterior es bastante simple, directo y bien respaldado por intelli sense, el "aspecto y tacto" de EventHandler no parece tan claro. El soporte por defecto de intelli sugerirá solo el manejador de eventos, no su genérico. Además, la notación se ve horrible:

private event EventHandler<MyClass> SomeEvent;
private event EventHandler<AnotehrClass> OtherEvent;
privete event EventHandler<MoreClass> MoreEvents;

Mientras visualiza el código, leerá "EventHandler" cada vez y su mente podría conectar a esos delegados, ya que se utiliza para identificar la relación de los tipos por sus nombres.

Por otro lado, también podría haber una explicación menos teórica y más técnica / lógica:
En primer lugar, siempre obtienes un objeto remitente en el método de manejo. Si bien esto parece útil a primera vista, siempre se usa cebada.
Además, sus argumentos deben derivarse de EventArgs, que pueden ser molestos o, a veces, imponerse debido al uso de componentes existentes.
Aparte de los genéricos típicos (por ejemplo, IList / List), se pierde la posibilidad de usar un tipo más abstracto (como una interfaz) o simplemente un tipo simple (como un doble).
Por último, pero no menos importante, existen aquellas reglas / sugerencias de notación introducidas por microsoft. Para su ejemplo sobre el evento enrutado, la regla podría decir que su tipo está "marcado" como enrutado al tener su nombre con la palabra "Enrutado". Mientras que el nombre del evento en sí mismo dice que el nombre comienza con una "Vista previa".

Como mencioné: esta es solo mi opinión, así que no me culpes;)

Answer 2

No creo que haya nada de malo en eso. Se usa en algunos lugares del marco ... en el evento GeoCoordinateWatcher.Position , solo como un ejemplo al azar.

Es un poco más torpe ver en el código que un nombre de tipo específico como RoutedEventHandler , y como va a utilizar RoutedEventHandler mucho en WPF / Silverlight, tal vez es por eso que MS decidió darle su propio tipo.

Answer 3

Solo un accidente de la historia. Si tuviéramos genéricos en .NET 1, la mayoría de los otros delegados no existirían.

Answer 4

También podría ser que cuando estás escribiendo código de nivel de marco, tiendes a ser más explícito. Cuando escribe el kit de herramientas y el código de nivel de aplicación, no es así.