J'apprends des événements en C # et je comprends que la classe eventargs porte des données sur l'événement. Mais j'ai des difficultés à comprendre pourquoi eventargs est nécessaire.
6 Réponses :
Les données passées dans evenargs ne sont pas nécessairement disponibles dans les propriétés de l'objet qui ont généré l'événement. Par exemple, sur un événement MouseDown, le Mouseeventargs inclut des informations sur la position actuelle de la souris. L'objet qui a généré cet événement ne stocke probablement même rien d'aussi volatile.
C'est logique. Mais est-ce nécessaire dans cet échantillon?
Oui. Même si vous pouviez obtenir sur les données d'une autre manière, s'il s'agit de suivre le modèle de tous les autres événements .NET, les evenargs doivent remplir les données relatives à l'événement.
Les majuscules avec la classe Eventargs sont (comme je le vois) principalement ces deux:
Il est peut-être même que les informations contenues dans les evenargs ne sont pas exposées par l'objet soulevant l'événement.
Bien sûr, dans certains cas, il peut sembler trop excédent, mais je pense que le pouvoir de la similitude est une bonne chose ici; Si vous savez comment un événement fonctionne, vous savez comment les autres événements fonctionnent également.
L'événement args est un excellent moyen de laisser l'abonné savoir quelle était la valeur préalable d'une propriété donnée pour un événement modifié des biens, en supposant que ces informations puissent être utiles.
eventargs est utile pour:
Pour développer le premier point ... Entre votre gestionnaire d'événements appelé et que vous lisez l'état de l'objet qui a soulevé l'événement, d'autres choses auraient pu arriver, ce qui a changé l'état à autre chose. Dans cette circonstance, vous réagiriez par exemple, un événement "alarmhasgoneoff" sur une liaison alarmclock où l'alarme a déjà été éteinte.
Il est également possible de répondre aux événements qui ont été soulevés "ailleurs" - que ce soit dans un autre processus / appdomain / processus sur une autre machine à travers divers mécanismes différents. Si vous deviez ensuite rappeler cela "ailleurs" pour obtenir les informations que vous avez obligées, cela pourrait prendre plusieurs secondes (ou moins, ou plus!), En faisant le passage de données utiles / requises via eventargs ou une classe dérivée une performance massive amélioration.
+1 état au moment du temps. Surtout pour le code de threadsafe.
Vous n'avez pas à passer eventarg.empty au gestionnaire. Vous pouvez transmettre n'importe quelle classe dérivée. Lorsqu'un gestionnaire d'événements est spécifié pour prendre eventargs comme paramètre, cela signifie qu'il n'y a pas d'arguments spécifiques qui sont toujours disponibles, mais vous voudrez peut-être passer la vôtre pour des informations supplémentaires.
La classe eventargs code> est nécessaire car si vous souhaitez étendre votre événement pour fournir plus d'informations à l'avenir, vous auriez des problèmes de portabilité pour tous les clients à l'aide de la méthode d'origine Signature de l'événement d'origine. Par exemple, P> public class MyClass
{
public event EventHandler /* (point 2) */ MyEvent; /* (point 1) */
// (point 3 + 4)
protected virtual void OnMyEvent()
{
EventHandler temp = MyEvent;
if (temp != null)
temp(this, EventArgs.Empty);
}
public void SomeMethodThatWillRaiseTheEvent()
{
....
OnMyEvent();
}
}
Une autre bonne chose que vous recevez de la suite du modèle standard, c'est que les personnes utilisant votre classe qui fournit à l'événement peut accrocher des gestionnaires d'événements courants: ne pas avoir à déclarer tous vos délégués personnalisés Pour déclarer vos événements, c'est bien, aussi. Si vous avez utilisé EventHandler