Uso de EventArgs para pasar información a la clase invocadora

Question

¿Está mal modificar EventArgs en controladores de eventos con el fin de pasar información a la clase que invoca el evento?

Por ejemplo, si tengo una clase de comunicación de bajo nivel que necesita validar un certificado para SSL pero no tiene forma de saber cómo es un certificado válido ya que es el conocimiento de los diferentes usuarios de la clase.

class ValidationEventArgs : System.EventArgs 
{ 
    public X509Certificate Certificate { get; set; } 
    public bool Valid { get; set; } 
} 

Luego, en los que utilizan objetos que conectar con el evento, y comprobar que de alguna manera cambiar la bandera Valid para indicar si el certificado es aceptable o no.

comms.ValidationEvent += CertValidationHandler; 

void CertValidationHandler(ValidationEventArgs args) 
{ 
    if (args.Certificate.Issuer.Contains(COMPANY_NAME) 
     args.Valid = true; 
} 

he encontrado references de EventArgs siendo utilizados como este, pero también he visto a la gente diciendo que no es recomendable.

Editar: Tal vez debería aclarar que no se trata de heredar EventArgs, sino de usarlos como un canal de comunicación bidireccional. Como otros comentaron, esto es aceptable y cualquier ruido que Google elija es probablemente solo que la gente haya malinterpretado o utilizado mal el concepto y ahora tiene la misma cruzada personal contra goto.

Answer 1

Hazte la siguiente pregunta: "cuando publico un evento, ¿deseo que cualquier suscriptor modifique alguno de los valores de EventArgs"? Si la respuesta es no, p. está transmitiendo información de solo lectura y luego hace que la clase sea inmutable; sin embargo, si necesita algún comentario de un suscriptor, haga que las propiedades que deban modificarse se puedan modificar.

Para aclarar, en un ejemplo de difusión, queremos decirle algo a cualquier suscriptor pero no permitir que alteren el valor.

public class ProgressEventArgs : EventArgs 
{ 
    public ProgressEventArgs(int current) 
    { 
     this.Current = current; 
    } 

    public int Current { get; private set; } 
} 

Igualmente, también podríamos plantear un evento para solicitar información que la clase en sí misma desconoce.

public class FeedbackEventArgs : EventArgs 
{ 
    public bool ShouldContinue { get; set; } 
    public string Reason { get; set; } 
} 

Answer 2

No tengo conocimiento de ninguna recomendación contra heredar de EventArgs; por lo que sé, heredar de él es una buena práctica.

Como principio general, sugiero que haga que sus clases derivadas sean inmutables. Eso hará que sea mucho más seguro pasar entre hilos en caso de que necesite hacerlo. La forma más sencilla de hacerlo es declarar sus propiedades como { get; private set; }, y solo establecerlas en el constructor. Obviamente no puedes hacer eso con el caso de uso específico que tienes en la pregunta, pero debes hacerlo siempre que sea posible.

Answer 3

Puede utilizar la clase EventArgs mediante el enfoque de Tipos genéricos. En este ejemplo, voy a utilizar la clase Rect con como tipo de retorno:

public EventHandler<Rect> SizeRectChanged; 

provocar el evento:

if(SizeRectChanged != null){ 
    Rect r = new Rect(0,0,0,0); 
    SizeRectChanged(this,r); 
} 

escuchar el evento:

anyElement.SizeRectChanged += OnSizeRectChanged; 

public void OnSizeRectChanged(object sender, Rect e){ 
    //TODO abything using the Rect class 
    e.Left = e.Top = e.Width = e.Height = 50; 
}