Il est connu que vous devez déclarer des événements qui prennent comme paramètres (object sender, EventArgs args) . Pourquoi ?
Réponses
Trop de publicités?
Cela permet au développeur consommateur d'écrire un seul gestionnaire d'événements pour plusieurs événements, indépendamment de l'expéditeur ou de l'événement.
Editer : Pourquoi auriez-vous besoin d'un modèle différent ? Vous pouvez hériter d'EventArgs pour fournir n'importe quelle quantité de données, et changer le modèle ne servira qu'à embrouiller et à frustrer tout développeur qui sera forcé d'utiliser ce nouveau modèle.
user6288
Points
514
En fait, on peut se demander s'il s'agit ou non de la meilleure façon d'organiser des événements. Certains pensent que les événements sont destinés à découpler deux segments de code, et que le fait que le gestionnaire d'événements reçoive l'expéditeur et doive savoir dans quel type l'expéditeur doit être coulé pour pouvoir faire quoi que ce soit avec lui est un mauvais modèle.
Eric Z Beard
Points
18473
Joe
Points
60749
L'utilisation d'un seul paramètre, EventArgs, pour les données transmises par un événement vous permet d'ajouter des données à votre événement dans les versions futures de votre logiciel sans interrompre les consommateurs existants. Il vous suffit d'ajouter de nouveaux membres à une classe existante dérivée de EventArgs ou de créer une classe dérivée avec les nouveaux membres.
Dans le cas contraire, la cohérence et le principe de moindre surprise justifient l'utilisation d'EventArgs pour le passage des données.
En ce qui concerne l'expéditeur, dans certains cas (mais pas tous), il est utile de savoir quel type a envoyé l'événement. L'utilisation d'un type autre qu'objet pour l'argument de l'expéditeur est trop restrictive : cela signifierait que d'autres expéditeurs ne pourraient pas réutiliser la même signature d'événement.
David Basarab
Points
25852
C'est un bon modèle à utiliser, de cette façon, ce qui met en œuvre l'événement peut trouver ce qui l'a envoyé.
La meilleure méthode consiste également à surcharger les EventArgs et à leur faire passer des données. Les EventArgs sont une classe de base. Si vous regardez les différents contrôles qui appellent des événements, ils ont surchargé les EventArgs qui vous donnent plus d'informations sur l'événement.
Même si vous n'avez pas besoin des arguments pour réaliser l'événement, si vous ne les incluez pas dans la première version du framework et que vous voulez les ajouter plus tard, vous casserez toutes les implémentations précédentes et devrez les réécrire. De plus, si vous créez un framework et que vous souhaitez le distribuer, la situation est pire car tous ceux qui utilisent votre framework devront le remanier.
