Appels automatiques de vérifications dans chaque méthode

Version imprimable

13/01/2009, 11h15
rockeye

Appels automatiques de vérifications dans chaque méthode
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:

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
13/01/2009, 11h24
Guulh

Connais-tu PostSharp ? Parce que ton besoin a l'air d'être pile poil dans les cordes de ce composant (à savoir l'AOP).
13/01/2009, 12h50
tomlev

Citation:

Envoyé par rockeye

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

Citation:

Envoyé par Guulh

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...
13/01/2009, 14h12
rockeye

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

Si il y a d'autres idées, je suis toujours preneur!
13/01/2009, 15h17
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 ?

Code:

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 ?

13/01/2009, 17h35
tomlev
Citation:
Envoyé par sperot51

Code:

1 2 public void methode(x as integer)
Tu nous fais du "VB#" ? ;)
13/01/2009, 17h49
Pol63

désolé, j'ai encore un peu de mal avec le c# ^^
16/01/2009, 10h05
rockeye

Merci à vous de vous penchez sur mon souci!

Citation:

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... :mrgreen:)
16/01/2009, 10h18
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 ...
16/01/2009, 11h05
tomlev

Citation:

Envoyé par rockeye

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 ?
16/01/2009, 16h31
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.
16/01/2009, 16h36
tomlev

Citation:

Envoyé par rockeye

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)

Citation:

Envoyé par rockeye

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...
16/01/2009, 16h50
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 ! :mrgreen::aie:
16/01/2009, 18h50
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
20/01/2009, 09h19
rockeye

Citation:

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 ! :king:

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!
20/01/2009, 10h08
tomlev

Citation:

Envoyé par rockeye

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...
20/01/2009, 10h39
Guulh

Citation:

Envoyé par tomlev

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