¿Es esta una mejor forma de activar/invocar eventos sin una comprobación nula en C#?

Question

mayor parte del código que he visto utiliza la siguiente manera de declarar e invocar evento de disparo:

public class MyExample 
{ 
    public event Action MyEvent; // could be an event EventHandler<EventArgs>, too 

    private void OnMyEvent() 
    { 
     var handler = this.MyEvent; // copy before access (to aviod race cond.) 
     if (handler != null) 
     { 
      handler(); 
     } 
    } 

    public void DoSomeThingsAndFireEvent() 
    { 
     // ... doing some things here 
     OnMyEvent(); 
    } 
} 

Incluso ReSharper genera un método de invocación de la manera mencionada anteriormente.

¿Por qué no hacerlo de esta manera:

public class MyExample 
{ 
    public event Action MyEvent = delegate {}; // init here, so it's never null 

    public void DoSomeThingsAndFireEvent() 
    { 
     // ... doing some things here 
     OnMyEvent(); // save to call directly because this can't be null 
    } 
} 

¿Puede alguien explicar por qué no una razón para hacer esto? (pro vs. contras)

Answer 1

Los pros y los contras son:

• cheques nulos son muy baratos; estamos hablando milmillonésimas de segundo. La asignación de un delegado y luego la recolección de basura sin éxito durante el resto de la vida útil del objeto podría llevar quizás más de millonésimas de segundo. Además, está consumiendo docenas de bytes más memoria. Además, cada vez que se dispara el evento, se obtiene una llamada innecesaria a un método que no hace nada, consumiendo incluso más microsegundos. Si usted es el tipo de persona que se preocupa por millonésimas de segundo y decenas de bytes, eso podría ser una diferencia significativa; para la gran mayoría de los casos, no lo hará.

• Debe recordar siempre crear el delegado vacío. ¿Es eso realmente más fácil que recordar comprobar nulo?

• Ninguno de los dos patrones realmente hace que el evento sea seguro. Todavía es completamente posible con ambos patrones que un controlador de eventos se active en un hilo mientras se elimina en otro hilo, y eso significa que compiten. Si el código de eliminación de controlador destruye el estado que el controlador necesita, entonces es posible que un hilo esté destruyendo ese estado mientras otro hilo ejecuta el controlador. No crea que la mera verificación de la nulidad o la asignación mágica de un controlador vacío eliminan las condiciones de carrera. Solo elimina la condición de anticipación que ocasiona la desreferenciación nula.

Answer 2

Es puede seguir siendo nulo. Consideremos:

var x = new MyExample(); 
    x.MyEvent += SomeHandler; 

    // ... later, when the above code is disposed of 

    x.MyEvent -= SomeHandler; 

EDIT: realidad, lo retiro. Después de haber probado esto, si ha utilizado un delegado anónimo para establecer el controlador, no parece que puede borrarlo, por lo que puede guardar la verificación nula.

No estoy seguro de si esto es un comportamiento fiable sin embargo, o simplemente un artefacto de la implementación del lenguaje ...

Answer 3

es una cosa de estilo a ciencia cierta; sin embargo, creo que la mayoría de los desarrolladores optan por la seguridad sobre el estilo en lo que respecta a los controles nulos. No hay nada en este mundo que pueda garantizar que un error no se infiltre en el sistema y que la verificación nula seguirá siendo innecesaria.

Answer 4

La mejor compensación que he visto para simplificar la activación de eventos es la adición de un método de extensión. Ver Raising C# events with an extension method - is it bad?.