J'ai examiné l'un de mes livres C # et je viens de voir une phrase sur les événements en C #: Quel que soit ce que cela signifie, oui en fait des événements travaillent à peu près comme des délégués. Y a-t-il quelqu'un qui peut expliquer la partie audacieuse?
Merci d'avance.
L'objectif principal des événements est d'empêcher les abonnés d'interférer les uns avec les autres .
Je me demandais pourquoi je devrais utiliser des événements au lieu de délégués.
4 Réponses :
Un événement ne peut être invoqué que par la classe qui le définit, alors qu'un délégué peut être invoqué à partir de qui lui a accès. C'est ici ce que je crois que les moyens de texte audacieux.
En outre, un événement peut être défini dans une interface, alors qu'un délégué ne peut (comme vous le déclareriez le délégué en tant que champ).
Je recommande de donner Ce lien a lu, car il l'explique assez bien et a Quelques autres exemples autres que ceux mentionnés ci-dessus.
Vous pourriez déclarer le délégué comme une propriété, bien sûr. Ce serait une analogie plus appropriée.
Je viens de regarder cet article - je ne l'ai pas tiré, car il le fait sonner comme des événements ne sont que des champs de type délégué modifiés. Il n'y a rien à dire qu'un événement doit être soutenu par un champ de ce type du tout . Ils sont plus comme des propriétés que les champs.
@Jon - Fair, peut comprendre cela.
Vous pouvez définir un délégué à NULL, ce qui l'empêche d'oublier toutes les fonctions qui lui sont souscrites.
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 un bien public ou un champ qui avait un type de délégué. Je suppose que c'est ce que vous voulez vraiment dire. Supposons efface donc le gestionnaire d'événements d'origine. De même, un autre code serait également capable de invoquer les gestionnaires d'événements: même si le bouton n'avait pas été cliqué. Ceci est clairement une violation de l'encapsulation. La seule raison d'exposer penser à événements comme sucre syntaxique autour de deux méthodes. Par exemple, si nous n'avions pas eu d'événements, Bouton aurait probablement: La violation de l'encapsulation disparaît, mais vous perdez une partie de La commodité - et tout le monde doit écrire leurs propres méthodes comme celle-là. Les événements simplifient ce modèle, fondamentalement. bouton.click était un champ public ou une propriété au lieu d'un événement. Une pièce de code pourrait ensuite souscrire à un événement, et une autre pourrait alors écrire: Cliquez sur vers un autre code consiste à leur permettre d'enregistrer les intérêts des clics de bouton et d'enregistrer désintérêt plus tard - et ce sont exactement les capacités que les événements fournissent.
Vous pouvez ajouter autant d'événementHandler à votre événement comme vous le souhaitez.
Les délégués sont également multidiffuseurs. En effet, un événement est généralement soutenu par un seul champ du type de délégué concerné.
Je pense que c'est en fait un mythe assez commun que les délégués sont singlecast. De nombreux développeurs C # que je sais pensent que la principale différence entre les deux est que les délégués sont à une seule fois que les événements sont multiples, mais ce n'est pas le cas!
Merci pour l'info. C'est vraiment nouveau pour moi: /!