Discussion :

[rockeye]

Bonjour,

j'ai eu du mal a donner un titre valable à mon sujet. Je vais éclaircir votre lanterne!

J'ai une série d'assertions à faire avant l'appel de chaque méthode d'un assembly. Je fais toutes ces vérif dans une méthode Prologue(). Chaque méthode est public.

Je voudrais appeler Prologue avant (ou au début) de chaque méthode. Je pense qu'il y a un moyen plus élégant que de faire ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public void methode1()
{
  Prologue();
  //Code propre à la méthode 1...
}
 
public void methode2()
{
  Prologue();
  //Code propre à la méthode 2...
}
...

Sur 2 méthodes, c'est pas génant, mais quand on passe à une centaine, ca devient lourd!

Je me demande s'il est possible avec la réflexion de capturer l'appel d'une méthode dans l'assembly, de lancer Prologue() et si tout est OK, de continuer avec la méthode appelée à l'origine ?

Est-ce qu'il y a un autre moyen ?

Merci

[Guulh]

Connais-tu PostSharp ? Parce que ton besoin a l'air d'être pile poil dans les cordes de ce composant (à savoir l'AOP).

[tomlev]

Je me demande s'il est possible avec la réflexion de capturer l'appel d'une méthode dans l'assembly

Si c'est possible, c'est sans doute extrêmement complexe, et probablement pas la meilleure solution...

Connais-tu PostSharp ? Parce que ton besoin a l'air d'être pile poil dans les cordes de ce composant (à savoir l'AOP).

+1 pour PostSharp
Par contre ça ne changera pas grand chose à la quantité de code à écrire... il faudra quand même mettre un attribut d'aspect sur chaque méthode. A moins qu'il soit possible de créer un aspect qu'on applique à la classe et qui sera automatiquement appliqué à chaque méthode, mais je connais pas assez bien PostSharp pour le dire...

[rockeye]

ok, merci. Je vais jeter un coup d'oeil sur PostSharp.

Si il y a d'autres idées, je suis toujours preneur!

[Guulh]

Ceci dit, je suis curieux de savoir dans quel scénario on se retrouve à avoir une centaine de méthodes avec les mêmes paramètres et les mêmes vérifications à faire sur ces paramètres. T'as pas des méthodes que tu peux regrouper ?

[Pol63]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public void methode(x as integer)
{
  prologue()
   /// appel à methode1 ou 2 ou x selon x
}
 
public void methode1()
{
  //Code propre à la méthode 1...
}
 
public void methode2()
{
  //Code propre à la méthode 2...
}
...

non ?

[tomlev]

Code :

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

1
2
 
public void methode(x as integer)

Tu nous fais du "VB#" ?

[Pol63]

désolé, j'ai encore un peu de mal avec le c# ^^

[rockeye]

Merci à vous de vous penchez sur mon souci!

Ceci dit, je suis curieux de savoir dans quel scénario on se retrouve à avoir une centaine de méthodes avec les mêmes paramètres et les mêmes vérifications à faire sur ces paramètres.

@Guulh : les méthodes n'ont pas forcement les mêmes paramètres. Par contre, elles ont toutes des vérifications communes.

En fait, j'ai une dll qui après avoir été chargé, doit être explicitement initialisée. Si cette initialisation n'est pas faite, ca plante parfois, et (plus grave) dès fois ca ne plante pas, mais le résultat de certaines méthodes n'est pas correct. Il est difficilement possible de modifier la DLL pour forcer l'intialisation.

Au final, je dois, dans chaque fonction, lancer une série d'asserts pour vérifier que l'initialisation a été faite et s'est bien déroulée.

@sperot51 : effectivement, si les fonctions n'avaient aucun argument, ca serait la meilleure solution. Mais j'avoue que mon exemple était un peu simpliste. Comme je l'ai dis juste au-dessus, les méthodes peuvent avoir différents arguments. Néanmoins, cette solution pourrait être envisageable, en passant un arg du type GenericArg et j'encapsule tous les arg nécessaires dans des classes filles, mais ca me semble lourd. Si j'ai n arguments différents, j'aurai n classes...

J'ai jeté un coup d'oeil à PostSharp et effectivement, ca devrait convenir.
Mais, je suis toujours un peu rétissant à utiliser des outils externes. Je cherche un autre moyen. Je me demandais avec un delegate sur l'appel des fonctions.

Dans mes reves les plus fous, je voudrais un truc du genre
-> Capter l'appel d'une méthode de l'assembly (genre Reflector.OnInvokeMethodCall)
-> Utiliser un délegate pour qu'à chaque appel soit fait les vérifs.
(bon, pour les curieux, je fais qd même d'autres rêves un peu mieux que du code... )

[Pol63]

sinon un autre moyen de taper plein de code sans s'embêter, c'est de faire un générateur de code

par exemple tu fais tes x méthodes en privés sans l'appel à ta méthode de test
puis tu appel un générateur que tu as fait qui via la reflection liste les méthodes et créé des méthodes publiques avec les meme paramètres qui appelle la méthode de test puis la méthode de privée avec les paramètres
tu finis par une copie dans le presse papier, tu reviens dans ton code et tu colles ce qu'il a été généré dans la classe (ou meme un partial class pour que ca soit plus pratique)
si en plus tu en rajoutes plus tard, tu relances la génération ...

[tomlev]

En fait, j'ai une dll qui après avoir été chargé, doit être explicitement initialisée. Si cette initialisation n'est pas faite, ca plante parfois, et (plus grave) dès fois ca ne plante pas, mais le résultat de certaines méthodes n'est pas correct. Il est difficilement possible de modifier la DLL pour forcer l'intialisation.

Pourquoi ne pas simplement initialiser la DLL dans le constructeur de ta classe ?

[rockeye]

La méthode du générateur, c'est classe! Ca me serait jamais venu à l'idée! Je vais fouiller!

@Tomlev: ben effectivement, c'est une possibilité. Mais c'est un peu plus compliqué que ca en pratique.
La Dll en question est écrite en C++/cli et contient pleins de fonctions globales, mélangées à des classes, et fait appel à des dll en pur C.
Si je lance l'initialisation dans le constructeur d'une classe, il se peut que ca génère une exception... ce qui est fortement déconseillé dans un constructeur.

Ma question concernait à l'origine plus des fonctions statiques justement, qui ne posent pas ce problème.

[tomlev]

Si je lance l'initialisation dans le constructeur d'une classe, il se peut que ca génère une exception... ce qui est fortement déconseillé dans un constructeur.

Ah bon ? Tu as vu ça où ? Pourtant il y a plein de classes dont le constructeur lève des exceptions (FileStream & cie par exemple)

Ma question concernait à l'origine plus des fonctions statiques justement, qui ne posent pas ce problème.

Tu peux utiliser un constructeur statique. Par contre là c'est peut-être un peu plus gênant de lever une exception...

[olibara]

+1 pour la solution de Tomlev c'est celle qui me semble la plus élégante et la plus perenne !

Par contre si tu a de l'energie a dépenser et des reves a exhausser, je me tournerais vers cette dll qui me semble bien fragile et capricieuse !

[Pol63]

je viens de tester le throw dans le constructeur static, histoire d'etre sur du déroulement
le premier appel au constructeur passe par constructeur static, comme je pensais
par contre les futures instanciations sont bloquées directes sans repasser dans aucun constructeur, la classe est comme vérouillée du à l'echec du shared sub new comme on dit chez nous

[rockeye]

Ah bon ? Tu as vu ça où ? Pourtant il y a plein de classes dont le constructeur lève des exceptions

http://jlecomte.ifrance.com/c++/c++-...ptions-fr.html :
Si un constructeur jette une exception, le destructeur de l'objet n'est pas exécuté. Si votre objet a déjà fait une chose qui doit être défaite [...], ce "truc qui doit être défait" devrait être gérer par un membre de donnée à l'intérieur de la classe.
A moins d'utiliser des smarts pointeurs, il semble que c'est risqué.


Merci pour l'idée du constructeur statique !

Ca va demander pas mal de refactoring, mais effectivement, c'est surement la meilleure solution. Ca me permettra de faire aussi un peu de ménage dans ce code!

Merci à tous pour votre participation et vos idées!

[tomlev]

http://jlecomte.ifrance.com/c++/c++-...ptions-fr.html :
Si un constructeur jette une exception, le destructeur de l'objet n'est pas exécuté. Si votre objet a déjà fait une chose qui doit être défaite [...], ce "truc qui doit être défait" devrait être gérer par un membre de donnée à l'intérieur de la classe.
A moins d'utiliser des smarts pointeurs, il semble que c'est risqué.

Euh... je ne te suis plus, là... on parle de C++ ou de C# ?
Si ce qui t'inquiète c'est de ne pas "nettoyer" quand tu lèves une exception dans le constructeur, tu peux toujours le faire avant de lever l'exception...

[Guulh]

Euh... je ne te suis plus, là... on parle de C++ ou de C# ?
Si ce qui t'inquiète c'est de ne pas "nettoyer" quand tu lèves une exception dans le constructeur, tu peux toujours le faire avant de lever l'exception...

Surtout que là, la seule chose à nettoyer serait éventuellement de décharger la dll ; et vu qu'on lève une exception précisément quand on y arrive pas...