¿Está bien agregar siempre un controlador de eventos vacío?

Question

Duplicar posible:
Is there a downside to adding an anonymous empty delegate on event declaration?

El siguiente patrón es bastante común cuando se utilizan controladores de eventos (en C#):

public event Action handler; 
… 
// some method: 
if(handler != null) handler(); 

¿Hay alguna desventajas de la asignación de un vacío delegado a este evento? Esto salvaría la condición if !=null en todas partes, donde se dispara el evento. Por supuesto, esto solo aplica, cuando no podemos garantizar que el evento siempre tenga asignado un delegado adecuado.

public event Action handler; 
… 
// in constructor: 
handler +=()=>{}; 
… 
// some method: 
handler(); 

Claro, hay un ligero golpe de rendimiento, pero hace que el código sea mucho más limpio. ¿Cuál es la mejor práctica en este caso? ¿Alguna desventaja técnica?

Answer 1

En lugar de agregar un delegado vacío en el constructor, puede ajustar el controlador en una función que primero verifica si el controlador es nulo y luego lo llama. La desventaja de esto es que si tienes muchos eventos, tendrás muchas funciones que envolverán cada evento.

private void HandlerWrapper() 
{ 
    Action localHandler = handler; 
    if (localHandler != null) handler(); 
} 

Answer 2

idea interesante, nunca he pensado en hacer eso. La forma en que hago mis eventos personalizados es hacer que OnCustomEventName tome parámetros para el evento y simplemente hacer la verificación allí para null. y llame a OnCustomEventName desde el código donde quiera que se desencadene el evento. Evita los golpes de rendimiento y mantiene el código operativo más limpio que un cheque de 2 líneas si lo deseas cada vez que deseas que se active el evento.

Dicho esto, esto no responde a la pregunta sobre las desventajas técnicas, sino que es más una buena práctica al disparar eventos.

código de ejemplo para la función "On" de enhebrado.

private void OnCustomEventName() 
{ 
    DelegateName localhandler = CustomEventName; 
    if (localhandler != null) 
     localhandler(); 
} 

Answer 3

Realmente no he encontrado ningún inconveniente importante para hacer esto y, en general, lo prefiero sobre la comprobación de nulo. El único problema que no puedo pensar es que podría dar lugar a pasos molestos en el código al depurar (es decir, que tiene que pasar por encima del delegado vacío cada vez que entra en un evento).

Creo que el rendimiento no es un problema: si el rendimiento de la aplicación degenera significativamente al invocar eventos, el evento probablemente no debería haber estado allí en primer lugar.