Discussion :

[cma]

Bonjour,

La signature habituel d'un délégué est (ByVal sender As Object, ByVal e As xxxEventArgs). Est-ce simplement une convention ou je me trompe ?
-> c'est une convention, rien n'empêche d'utiliser 0 à x arguments

J'utilise les évènements pour faire dialoguer entre-elle les couches de mon application. La couches applicative est abonnée aux couches techniques. Je joue avec des interfaces pour découpler les dépendances. Après je propage les évènements plus ou moins en l'état à la couche présentation. Dans ce cas le sender peu prendre différente forme, Me ou une autre instance, selon les besoins.

Dans les exemples que j'ai trouvé, e est systématiquement utilisé. Ceci implique de créer autant de classe dérivée que d'évènements. Avec un modèle en couche, cela augmente d'autant le nombre d'interface vu que les évènements... Du coup, je n'utilise jamais ce paramètre. Mais ça me titille..

Pourquoi utiliser un xxxEventArgs alors que le sender contient déjà toutes les infos et qu'il est possible de les "filtrer" via des interfaces?
-> c'est utile lorsque les infos à transmettre aux abonnés sortent du cadre de l'émetteur
Existe-t-il des problèmes potentiels avec la méthode que j'utilise?
-> ils sont d'ordre philosophique

Merci pour votre aide

[olsimare]

Bonjour.

Bonjour,
La signature habituel d'un délégué est (ByVal sender As Object, ByVal e As xxxEventArgs). Est-ce simplement une convention ou je me trompe ?

J'utilise des tas de Handler avec des signatures différentes de celle-là. Je pense que cette signature est juste tirée d'un constat logique :
- c'est toujours utile de savoir qui à levée l'event
- la mise à disposition de donnée non accessibles via le sender peut être nécessaires.

Dans les exemples que j'ai trouvé, e est systématiquement utilisé. Ceci implique de créer autant de classe dérivée que d'évènements.

Ca n'a rien d'obligatoire. Exemple --> si l'event n'a d'intérêt que de part sa levée, j'utilise un handler sans aucun paramétre.

Pourquoi utiliser un xxxEventArgs alors que le sender contient déjà toutes les infos et qu'il est possible de les "filtrer" via des interfaces?
Existe-t-il des problèmes potentiels avec la méthode que j'utilise?

Clairement oui, à proscrire. Cela implique que tu dois rendre public (ou friend) toutes les propriétés du sender que tu utilises dans les procédures déléguées. Imaginons que je veuille propager l'event saisie d'un caractére à partir d'une classe gérant un hook clavier. Ta méthode oblige à créer une propriété public "caractéreSaisi" et à l'alimenter avant la levée de l'event sachant que cette propriété ne sert à rien d'autre.

Illustration à 2 cents :
Moi et ma femme.
Méthode 1 avec argument :
Ma femme : "Je sors chercher le pain" --> event ( sender = ma femme, args = "je sors chercher le pain" )
Moi : "ok"
Méthode 2 sans argument :
Ma femme : "Je sors chercher le pain" --> event ( sender = ma femme)
Moi : "hein ? T'as dis quoi ? ..."
Trop tard, je le saurais jamais, elle est déjà partie...

Je joue avec des interfaces pour découpler les dépendances.

Avec de bons implements, ça le fera !

Cdt.

[SirJulio]

La signature habituel d'un délégué est (ByVal sender As Object, ByVal e As xxxEventArgs). Est-ce simplement une convention ou je me trompe ?

Salut,

Olsimare a deja repondu, mais je vais juste donner mon avis.

Rien ne t'oblige techniquement à le faire, mais c'est un cadre admis et conseillé. De plus, dans le cas ou un event n'a d'interet que dans sa levée (le sender et l'arg n'ayant aucune utilité), tu n'es pas obligé de créer un nouveau XXXEventArgs, tu peux garder un EventArgs simple (c'est ce que fait le Fx dans ses events standard sans argument (Click, Load, etc ).

Dans le cas, ou il y a des infos à passer, cela va dependre de l'info. Par exemple, si la donnée en question est recuperable sur une propriété existante (comprendre qui n'a pas été créé pour l'occasion) du sender, alors tu gardes la sig (Object, EventArgs) car tu pourras caster ton sender et recuperer l'info en question (cas de TextChanged de Control par exemple). A contrario, si la donnée n'est pas exposé explicitement par le sender, alors la oui, il faudra deriver un EventArgs afin qu'il encapsule les données en question (Exemple, toujours sur Control, KeyPressed ou Paint).

Bref, techniquement, tu es assez libre, mais AMHA, il vaut mieux s'en tenir à ce design. =)

[cma]

Un grand merci pour vos réponses.

Je constate que c'est plus une question philosophique que technique.

On ne perd rien à implémenter systématiquement la signature "conventionnelle" : les méthodes abonnées sont faciles à identifier, on garde une porte ouverte (est déjà implémentée) si on décide un jour de passer des argument supplémentaire

olsimare Je crois que tu peux passer une collection hétérogène en paramètre... en tout cas avec ma femme...

[Bluedeep]

On peut ajouter aussi que avec l'EventHandler générique, il n'y a normalement pas à créer de signature spécifique, juste hériter la class EventArg et déclarer l'event en utilisant le handler générique. Exemple :

Code :

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

1
2
3
4
5
6
7
 
public event EventHandler<MyEventArgs> MyEvent;
 
public class MyEventArgs : EventArgs
{
    public string MyField;
}