Héritage d'événements event EventHandler

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.

Salut,

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

Code:

---

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.

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?

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 :P :aie:

Citation:

---

Envoyé par Tober

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 ???

Ah oui, je confond avec le C++ :oops:
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 :)

Citation:

---

Envoyé par stephane.julien

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 :aie:)

Citation:

---

Envoyé par Tober

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 :)

---

Comme je disais tout à l'heure, un event est une propriété de type delegate, c'est un à dire grossièrement un tableau de pointeurs de fonctions. Il aurait donc du mal à être virtuel.

D'où l'existence de fonctions OnTruc virtuelles et surchargeables, qui sont les seules à déclencher des events :)

c'est ce que je voulais dire par "Tous les evenement" :P
"Tous les OnMachinChanged" si tu preferes :roll:

Citation:

---

Envoyé par Guulh

un event est une propriété de type delegate, ... . Il aurait donc du mal à être virtuel.

---

Avant cette discussion, j'ai testé les event virtuels et ça fonctionne. De même que les event abstract ... !

Par contre, dorénavant, je pense que je ne vais plus travailler comme ça, je vais plutot travailler avec les OnMachinChanged..

Citation:

---

Envoyé par Tober

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 :)

---

Je ne suis pas persuadé. Si .Net n'avait pas ses méthodes OnMachinChanged virtuelles, je ne les mettrais pas virtuelles. Cela permet d'éviter le fait que quelq'un qui hérite de la classe mère ne peut pas éviter le lancement de l'événement en appelant OnMachinChanged

Je suis presque convaincu par :

Citation:

---

Envoyé par Guulh

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.

---

Mais en même temps, si OnMachinChanged n'est pas virtuel, on peut imaginer que la classe fille fait son propre code dans sa propre méthode avant d'appeler OnMachinChanged, qui revient au même que de redéfinir OnMachinChanged... :lol:

J'ai l'impression de parler chinois :D

Citation:

---

Envoyé par stephane.julien

Mais en même temps, si OnMachinChanged n'est pas virtuel, on peut imaginer que la classe fille fait son propre code dans sa propre méthode avant d'appeler OnMachinChanged, qui revient au même que de redéfinir OnMachinChanged... :lol:

---

Ca ne revient pas au même, parce que seules les fonctions virtuelles permettent à du code de la classe mère d'appeler du code de la classe fille.

Et c'est précisément ce qu'on veut, là :)

Tu parles chinois !

Ton probleme c'est d'avoir le droit d'utiliser les evenement ? :aie:

Citation:

---

Envoyé par Guulh

Ca ne revient pas au même, parce que seules les fonctions virtuelles permettent à du code de la classe mère d'appeler du code de la classe fille.

Et c'est précisément ce qu'on veut, là :)

---

Oui c'est juste. Je ne l'avais pas vu comme ça ... :)

Je crois que j'ai la réponse que je voulais. A pratiquer pour en être convaincu... :)

Merci pour les réponses !

Citation:

---

Envoyé par stephane.julien

Avant cette discussion, j'ai testé les event virtuels et ça fonctionne. De même que les event abstract ... !

---

Effectivement, les events virtuels existent. Me suis gourré :) Un event est une propriété de type delegate, c'est donc une paire de fonctions : mais là où une propriété "normale" est une paire "get / set", un event est une paire "Add / Remove". (qui définit le comportement de truc.Bidule += Methode).

Mais virtualiser un event n'a visiblement de sens que si l'on souhaite surcharger la façon d'ajouter / enlever une fonction abonnée. ce qui n'est pas ton cas :)

cf http://blogs.msdn.com/samng/archive/...ents-in-c.aspx par exemple.

On en apprend tous les jours :)

Effectivement, on en apprend tous les jours. Je ne connaissais pas la déclaration du style :

Code:

---

1 2 3 4 5 6

public virtual event EventHandler case3_event { add { } remove { } }

---

J'en profite pour remercier tous les paraticipants au forum. Il est vraiment nikel ! :king: