Discussion :

[stephane.julien]

Bonjour,

J'ai une classe abstraite dans laquelle je déclare un événement event EventHandler. Je remarque avec surprise qu'il n'est pas possible de lancer l'événement depuis les classes enfant? Est-ce juste ou j'ai fait une faute?

Si c'est juste, comment lancer des événements depuis les classes enfants?

• Définition d'une méthode protected dans la classe abstraite qui lance l'événement ?
• Définir l'événement en tant que virtual et le redéfinir dans les classees enfant ?
• ... ?

Merci d'avance de votre opinion / aide.

[Guulh]

Salut,

Le pattern qu'on retrouve souvent dans les WinForms notamment est le suivant :

Code :

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

1
2
3
4
5
6
7
8
9
class Mere
{
public EventHandler MachinChanged;
protected virtual void OnMachinChanged(EventArgs e)
{
  if (MachinChanged ! null)
    MachinChanged(this, e);
}
}

C'est ce que t'as mis dans ton premier point
Et les classes filles n'ont qu'à lancer OnMachinChanged pour déclencher l'event.

Un event est une propriété de type delegate, ce n'est pas une méthode, il n'a donc pas lieu d'être virtuel.

[stephane.julien]

Oui c'est ce que j'ai pu comprendre en regardant également dans les WinForms. La question que je me pose, c'est pourquoi la méthode OnMachinChanged est virtuelle ? Si celle ci est redéfinie par la classe enfant et qu'elle n'appelle pas base.OnMachinChanged(), l'événement ne sera pas lancé... Je trouve cela pas terrible...

Et je me pose également la question suivante : Pourquoi l'événement ne peut pas être lancé directement depuis la classe enfant ??? S'il est internal, public ou protected, on devrait à avoir accès de la même manière qu'une méthode, non?

[Tober]

On utilise le mot clef virtual pour une bonne raison !
Si t'as une classe A qui est derrive en une classe B.
Dans B, tu devra redefinir imperativement toutes les fonctions virtual de A.
Par exemple, une Composant graphique est une interface, et tout le monde sait qu'un composant graphique doit pouvoir s'afficher...
D'ou l'utilisation d'une methode virtual Paint qui va permettre de dessiner un composant graphique...
Donc quand tu vas derriver la classe Composant, tu devrais reecrire la fonction Paint decrivant comment afficher ce composant precis.

Et apres, tu pourra avoir par exemple une liste de Composant (Sans savoir ce qu'il represente, et appele la fonction Paint qui sera automatiquement transtype dans le type du composant...

Bon, je suis peut etre pas completement clair, mais dans ma tete, c'est tres claire

[stephane.julien]

Dans B, tu devra redefinir imperativement toutes les fonctions virtual de A.

Pas d'accord. Ce sont les méthodes abstract que tu dois redéfinir impérativement. Les méthodes virtual ne doivent pas être redéfinies obligatoirement. Sur le reste, je suis d'accord.

Par contre je ne comprends pas pourquoi la méthode OnMachinChanged en particuler est virtual ???

[Tober]

Ah oui, je confond avec le C++
Tous les evenement a mon avis doivent etre virtual, pour permettre a n'importe qui de pouvoir changer le comportement de l'evenement en question comme bon lui semble

[Guulh]

Par contre je ne comprends pas pourquoi la méthode OnMachinChanged en particuler est virtual ???

Justement pour que les classes filles puissent déclencher l'event, visiblement.

Par exemple, la class Form et son event Load. Il est public, donc n'importe qui peut exécuter n'importe quel code lorsqu'il est déclenché. La classe fille est avantagée, parce que plutôt que base.Load += uneFonction (qu'elle peut faire comme tout le monde), elle peut faire override OnLoad, qui sera lancée avant l'event. (puisqu'un appel de OnLoad dans la classe mère va appeler cette surcharge, qui elle-même dans 99% des cas appelle la fonction de base)

Sans les fonctions OnMachin, la classe fille ne serait qu'une abonnée parmi d'autres.

(je sais pas si c'est l'explication officielle mais c'est ce qui me parait le plus logique )