¿Debo usar EventArgs o un tipo de datos simple?

Question

Actualmente estoy creando una biblioteca para divertirme y practicar y me preguntaba, al plantear un evento, cómo elegir entre pasar su propio derivativo de EventArgs o simplemente el tipo de datos.

Por ejemplo, en mi biblioteca tengo algo como esto:

public delegate void LostConnectionEventHandler(string address); 
public delegate void MessageReceieved(byte[] bytes); 

Cuál es la práctica estándar para esto? ¿Debo reemplazar string address con ConnectionEventArgs y byte[] bytes con MessageEventArgs?

Sé que cualquiera de los dos funciona bien y esta pregunta puede ser subjetiva, pero todavía tengo curiosidad sobre el proceso de pensamiento que los programadores de mayor nivel tienen cuando deciden si incluir o no sus propios EventArgs o simplemente pasar los datos directamente .

Gracias!

Answer 1

Las directrices de .NET Framework indican que el tipo de delegado utilizado para un evento debe tomar dos parámetros, un parámetro de "fuente de objeto" indicando la fuente del evento, y un parámetro de "e" que encapsula cualquier información adicional sobre el evento. El tipo de el parámetro "e" debe derivar de la clase EventArgs. Para los eventos que no usan ninguna información adicional, .NET Framework tiene ya definido un tipo de delegado apropiado: EventHandler.

Referencia: http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

Otra información útil: http://msdn.microsoft.com/en-us/library/ms229011.aspx

Answer 2

Dentro de mis proyectos, utilizo EventArgs cuando el número de parámetros es mayor que uno. Mire el evento NotifyPropertyChanged, tiene un argumento, que no es un tipo EventArgs.

Answer 3

No es necesario derivar de EventArgs, pero la convención sigue la regla de refactorización común (Introduce Parameter Object). Y la razón de esta regla está bien documentada.

Answer 4

Personalmente me gusta la idea de que deriva de EventArgs,

si tiene que pasar información de estado y los objetos agregados fácilmente se podría hacer él, vea el

MouseEventArgs tipo por ejemplo.

utilizando el enfoque OOP, si tiene un evento/construcción que acepta un objeto de tipo EventArgs puede confiar en el hecho de que cada objeto derivado de él funcionará de la misma manera, mientras que si tiene otro tipo de objeto que lo hace no compartir la misma clase base, eventualmente podrías romper algo.

difícil de probar y reproducirse pero posible, dependiendo del diseño, porque los eventos son delegados especiales diseñados para trabajar con EventArgs y sus descendientes

Answer 5

En un proyecto más amplio, que tienen una clase EventArgs, ayuda a minimizar el código que tiene para modificar, cuando su evento necesita datos adicionales en algunos casos. Normalmente prefiero el método EventArgs en lugar de un valor directo.