Le choix ne serait pas vraiment entre un délégué et un événement - ce sont des choses complètement différentes. Vous pouvez toutefois exposer une propriété publique ou un champ public ayant un type de délégué. Je suppose que c'est ce que vous voulez vraiment dire. Supposons que Button.Click était un champ ou une propriété publique au lieu d'un événement. Un morceau de code pourrait alors souscrire à un événement, et une autre pourrait alors écrire:
// Invalid with events, valid with properties
button.Click = null;
effaçant ainsi le gestionnaire d'événements d'origine. De même autre code serait également en mesure de Invoke les gestionnaires d'événements:
// Invalid with events, valid with properties
button.Click(this, EventArgs.Empty);
même si le bouton n'a pas été cliqué. Ceci est clairement une violation de l'encapsulation. La seule raison d'exposer Click à un autre code est de leur permettre d'enregistrer un intérêt dans les clics sur les boutons et d'enregistrer un désintérêt plus tard - et ce sont exactement les capacités que les événements fournissent. Pensez aux événements comme du sucre syntaxique autour de deux méthodes. Par exemple, si nous ne disposions pas d'événements alors Button aurait probablement:
public void AddClickHandler(EventHandler handler)
public void RemoveClickHandler(EventHandler handler)
La violation de l'encapsulation va, mais vous perdez une partie de la commodité - et tout le monde doit écrire leurs propres méthodes de ce genre. Les événements simplifient ce modèle, fondamentalement.
Vous pouvez déclarer le délégué comme une propriété, bien sûr. Ce serait une analogie plus appropriée. –
Je viens de jeter un coup d'oeil à cet article - je n'y tiens pas tellement car cela donne l'impression que les événements sont simplement des champs de type délégué. Il n'y a rien à dire qu'un événement doit être soutenu par un champ de ce type * du tout *.Ils ressemblent plus à des propriétés qu'à des champs. –
@Jon - Juste, peut comprendre cela. –