Discussion :

[Rapha222]

Salut,
Sur le MSDN, on peut lire que System.EventArgs est une classe qui sert de base pour passer des arguments lors d'un évènement:

Si le gestionnaire d'événements nécessite des informations d'état, l'application doit dériver une classe à partir de cette classe pour contenir les données.

On dit également qu'elle doit être utilisée avec les évènement, même si on a rien a passer:

elle est utilisée par des événements qui ne passent pas d'informations d'état à un gestionnaire d'événements lorsqu'un événement est déclenché.

Elle est donc inutile dans le cas d'un évènement qui ne passe rien. Quel est alors l'intérêt d'instancier une classe qui ne nous servira jamais ? Est-ce qu'il y a un avantage à utiliser cette technique plutôt que de créer un évènement qui n'envoi pas cet objet (MonEvent(object Sender) à la place de MonEvent(object Sender, EventArgs Args)).

Aussi, si nous n'avons besoin que d'envoyer un seul objet en argument d'un évènement, où est l'intérêt de créer une nouvelle classe ?
Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public delegate void OnNameChange(object Sender, DeriveeDeEventArgs Args)
// Au lieu de :
public delegate void OnNameChange(object Sender, string NewName)

Je comprends qu'on puisse recommander d'utiliser EventArgs pour des soucis d'homogénéité, mais techniquement ca ne semble offrir rien, si ce n'est une perte de temps.

Merci

Raphael

[StormimOn]

Elle est donc inutile dans le cas d'un évènement qui ne passe rien. Quel est alors l'intérêt d'instancier une classe qui ne nous servira jamais ? ...
Aussi, si nous n'avons besoin que d'envoyer un seul objet en argument d'un évènement, où est l'intérêt de créer une nouvelle classe ?

L'intérêt c'est principalement le respect d'un standard dans la façon de créer les événements et ce n'est pas rien. Dans une moindre mesure la contravariance si elle peut avoir son utilité.

Sinon pas la peine d'instancier un objet de type EventArgs, il y a une propriété statique EventArgs.Empty pour ça justement. Pas la peine non plus d'utiliser des délégués à partir du Framework 2.0, les classes EventHandler et EventHandler<T> permettent de faire ça très bien.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// Méthodes abonnées : object, EventArgs
public event EventHandler MyEvent; 
// Méthodes abonnées : object, MyEventArgs
public event EventHandler<MyEventArgs> OtherEvent;

Je comprends qu'on puisse recommander d'utiliser EventArgs pour des soucis d'homogénéité, mais techniquement ca ne semble offrir rien, si ce n'est une perte de temps.

La perte de temps est une fausse excuse compte tenu du fait :
- que tu devras le faire de toute façon si tu as plusieurs informations à passer (plusieurs champs donc)
- que cela prend 30 secondes à faire une classe qui encapsule un champ si on sait se servir des snippets et tu ne passes certainement pas tout ton temps à faire ce type de classe
- utiliser EventArgs.Empty est très rapide.

Sinon techniquement il y a plein de choses qui n'apporte rien parce que le but n'est pas un apport technique justement. On gagne alors en homogénéité, compréhension du code, ... en respectant ces standards qui semblent ne rien apporter

Si tu ne veux pas respecter les standards et que tu es seul sur ton code, libre à toi de le faire comme tu le sens. On ne peut que te conseiller très fortement de le faire pour prendre de bonnes habitudes

[Rapha222]

L'intérêt c'est principalement le respect d'un standard dans la façon de créer les événements et ce n'est pas rien. Dans une moindre mesure la contravariance si elle peut avoir son utilité.

Sinon pas la peine d'instancier un objet de type EventArgs, il y a une propriété statique EventArgs.Empty pour ça justement. Pas la peine non plus d'utiliser des délégués à partir du Framework 2.0, les classes EventHandler et EventHandler<T> permettent de faire ça très bien.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// Méthodes abonnées : object, EventArgs
public event EventHandler MyEvent; 
// Méthodes abonnées : object, MyEventArgs
public event EventHandler<MyEventArgs> OtherEvent;

La perte de temps est une fausse excuse compte tenu du fait :
- que tu devras le faire de toute façon si tu as plusieurs informations à passer (plusieurs champs donc)
- que cela prend 30 secondes à faire une classe qui encapsule un champ si on sait se servir des snippets et tu ne passes certainement pas tout ton temps à faire ce type de classe
- utiliser EventArgs.Empty est très rapide.

Sinon techniquement il y a plein de choses qui n'apporte rien parce que le but n'est pas un apport technique justement. On gagne alors en homogénéité, compréhension du code, ... en respectant ces standards qui semblent ne rien apporter

Si tu ne veux pas respecter les standards et que tu es seul sur ton code, libre à toi de le faire comme tu le sens. On ne peut que te conseiller très fortement de le faire pour prendre de bonnes habitudes

Merci, je connaissais pas EventHandler, ca change tout .