Discussion :

[Neewd]

Bonjour,

Je viens vers vous car j'ai un problème que je ne sais résoudre.

J'ai une List<MethodInfo> que j'appelle grâce à un Invoke(), comme ceci.

Code :

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

1
2
3
4
5
6
 
foreach (var meth in lesMethodesQuilFautInvoker)
{
      object[] parameters = { mesParametresDeMethodes };
      meth.Invoke(m_handler, parameters);
}

Ici mesParametresDeMethodes est quelque chose d'arbitraire que j'ai mis pour montrer que ce sont les paramètres.

Chaque méthode est construit de la même façon, et certaines d'entre eux lance des événements, comme ceci :

Code :

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

TextReceived(null, new TextReceivedEventArgs(text));

Ici j'ai mis un événement TextReceived, mais ça peut être un événement qui porte un nom totalement différent, selon la méthode appelée.

Ma question est, comment m'abonner à cet événement sachant que mon objet "m_handler" est lui aussi créé par reflexion.

Code :

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

m_handler = (IHandler) Activator.CreateInstance(typeOfTheHandler);

Je ne peux pas faire de m_handler.TextReceived + = laMethode puisque m_handler, au moment de la compilation est un IHandler et c'est au moment de l'exécution qu'il se transformera dans le type d'objet héritant de IHandler.

Comment puis-je capter cet événement ?

Merci beaucoup pour votre aide, là je sèche complètement,

[theMonz31]

une interface peut définir un évènement... donc, tu peux très bien abonné l'event sur une méthode...

[Neewd]

Donc je dois rattacher tous les évènements possibles de toutes les classes héritant de IHandler, dans mon interface ?

[theMonz31]

tous les event, je ne sais pas, mais au moins ceux dont tu veux récupérer le déclenchement.

Pour info, en terme de performance, trop utiliser les interfaces n'est pas l'idéal... il vaut mieux parfois utiliser des classes plutôt que des interfaces
car, tu y gagnes beaucoup en vitesse d'exécution (la reflection est un mécanisme "coûteux" en temps d'exécution)...

(J'avais déjà testé dans une application où tout était définit via interface, et au final, on a opté pour limiter grandement les interfaces, qui a diminuer les 12000 types
de pattern qu'un collègue voulait absolument ie: decorator, etc...)

[Neewd]

Oui je sais très bien que la performance s'en ressent.

En fait, c'est lorsque je reçois un packet sur le réseau, je veux l'orienter vers la classe qui se charge de ce type de packet. Un se charge des packets clients par exemple.
Donc j'ai un certains nombres de classe en fonction des catégories de packet, c'est un choix de ma part. Je pourrais tout mettre dans la même classe et tous les packets seraient gérées par cette classe mais ça sera vite le bordel.

Donc au moment de la réception j'identifie la catégorie pour connaitre la classe (qui hérite d'IHandler) vers laquelle je vais l'orienter.
C'est pour ça que j'ai définie une interface, pour pouvoir faciliter la création via Activator.

Car mettre tous les évènements que je veux récupérer dans l'interface reviendrait au premier choix que je voulais éviter

C'est impossible de faire un EventHandler custom que l'on attache au MethodInfo.Invoke ?

[theMonz31]

bonjour

Pour la dernière question, je n'ai pas d'idée pour l'instant.

Pour ce qui est de la gestion des envois en réseau, en général, je travaille avec une classe qui envoie les données avec un payload....

genre :

Code :

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

1
2
3
4
5
Class PacketEncapsulation
{
       un enum pour le type... (par exemple)
       object payload  (l'objet qui contient l'information)...
}

et après, en fonction du type de l'objet, je fais un cast approprié...

Evidemment, dans mon utilisation, je n'ai pas 12000 classes, donc, je n'ai pas vraiment l'intérêt à mettre en place en mécanisme qui me permettra de facilement
ajouter de nouvelles classes puisque je pars sur des situations relativement simples, peu évolutives et maitrisées dès le début...

En général, mais je fais que des programmes pour des "PME", je préfère éviter les systèmes qui permettent de facilement ajouter pleins de choses parce que:

1 - C'est plus compliqué à développer (enfin, plus long souvent)
2 - Un peu "usine" à gaz

et surtout au final, on se rend compte que souvent, tous les mécanismes mis en place pour aider à une évolution du soft, ajout de fonctionnalité, etc.. , ne servira pas
car le client ne fera jamais les évolutions...

voilà.. c'est juste un petit retour sur Expérience...