La elección no sería realmente entre un delegado y un evento: son cosas completamente diferentes. Sin embargo, podría exponer una propiedad pública o un campo público que tenía un tipo de delegado. Supongo que eso es lo que realmente quieres decir.
Suponer que Button.Click fuera del dominio público o propiedad en lugar de un evento. Una pieza de código podría entonces suscribirse a un evento y otro, entonces podría escribir:
// Invalid with events, valid with properties
button.Click = null;
limpiando de este modo el controlador de eventos originales. Del mismo modo otro código también sería capaz de invocación los controladores de eventos:
// Invalid with events, valid with properties
button.Click(this, EventArgs.Empty);
a pesar de que no se ha hecho clic en el botón. Esto es claramente una violación de la encapsulación. La única razón para exponer Click a otro código es permitirles registrar interés en los clics de botón y registrar el desinterés más tarde, y esas son exactamente las habilidades que proporcionan los eventos.
Piense en los eventos como azúcar sintáctico en torno a dos métodos. Por ejemplo, si no tenemos eventos a continuación Button probablemente tendría:
public void AddClickHandler(EventHandler handler)
public void RemoveClickHandler(EventHandler handler)
La violación de encapsulación se va, pero se perderá parte de la comodidad - y todos tienen que escribir sus propios métodos por el estilo. Los eventos simplifican este patrón, básicamente.
Usted podría declarar al delegado como una propiedad, por supuesto. Esa sería una analogía más apropiada. –
Acabo de echarle un vistazo a ese artículo; no me gusta, ya que suena como que los eventos son solo campos modificados de tipo delegado. No hay nada que decir que un evento tiene que estar respaldado por un campo de ese tipo * en absoluto *.Son más como propiedades que campos. –
@Jon - Justo, puede entender eso. –