Discussion :

[Loko]

Bonjour

Je voudrais écrire une fonction générique de controle de validité de dates. Pour faire court, par exemple verifier que datedeb<=datefin.

Le controle serait effectué sur toutes les occurences d'une liste passée en paramètre.

Mon souci est que les objets de type liste qui existent dans mon appli n'ont pas tous des propriétés qui s'appellent "datedeb" et "datefin", ca peut ausis etre "datedebut" par exemple.

Du coup je pensais passer en parametre le nom des propriétés, mais comment ensuite l'utiliser pour faire les contrôles ?

Genre :

Code :

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

1
2
3
4
private void TestDates ( List<T> l, string pNomDatedeb , string pNomDateFin)
{
  l[0].???? // comment utiliser ici le nom de la propriété obtenu en parametre ?
}

[BenoitM]

euh le mieux c'est de renommé tes propriétés correctement

De faire implémenter par tes objets une Interface

ou sinon tu peux tester d.GetType().GetProperty("propertyName").GetValue(d, null); mais je pense que c'est très couteux en performance

[Loko]

euh le mieux c'est de renommé tes propriétés correctement

mmmmouais, j'y ai pensé mais c'est un peu lourd pour si peu, et on aurait pas de certitude qu'un développeur par la suite n'utilise pas le nom de propriété qu'il faut.

De faire implémenter par tes objets une Interface

Là ca me parle plus, ca oblige effectivement à avoir le meme nom partout, meme si ca oblige à renommer l'existant

ou sinon tu peux tester d.GetType().GetProperty("propertyName").GetValue(d, null); mais je pense que c'est très couteux en performance

Je vais le tenter qd meme, pour voir

Merci

[Er3van]

Je confirme. A part avec de la réflexion, tu ne pourras pas procéder ainsi.

Et la réflexion ça peut être coûteux en performance. Vu que tu le fais en "dynamique", je dirais que ça peut l'être particulièrement dans ton cas. Mais selon tes attentes, ça peut malgré tout répondre à ton problème.

Cependant, on ne fait pas de la réflexion pour éviter d'avoir à faire un refactoring du code... donc je te conseillerai d'écouter la remarque de BenoitM.

[Loko]

Je confirme. A part avec de la réflexion, tu ne pourras pas procéder ainsi.

Et la réflexion ça peut être coûteux en performance. Vu que tu le fais en "dynamique", je dirais que ça peut l'être particulièrement dans ton cas. Mais selon tes attentes, ça peut malgré tout répondre à ton problème.

Cependant, on ne fait pas de la réflexion pour éviter d'avoir à faire un refactoring du code... donc je te conseillerai d'écouter la remarque de BenoitM.

Salut. N'étant pas expert, je me doute que quand tu parles de "réflexion" ce n'est pas le sens commun mais que ca désigne qqchose de précis dans le cas qui nous occupe, ca désigne le GetProperty ?

Pour ce qui est de ta remarque générale, je suis d'accord .... mais il faut aussi voir le cout de ce refactoring (et de tous les tests à refaire qui vont avec), des délais imposés, des dispos des testeurs, etc ... Malheureusement on est pas toujours dans les situations idéales où l'on peut faire tout comme on aimerait, sinon j'aurais déjà opté pour la réécriture du code.

[BenoitM]

Avec visual studio 2010 renommer(champ,propriétés,fonction) est assez facile et marche plutot bien

[Loko]

Tout a fait vrai, je m'en sers parfois.

Faut juste que j'arrive à vendre le truc au niveau des chefs de projets, car il faudra tout retester (ils sont pointilleux là dessus)

Merci à vous.

[Er3van]

Salut. N'étant pas expert, je me doute que quand tu parles de "réflexion" ce n'est pas le sens commun mais que ca désigne qqchose de précis dans le cas qui nous occupe, ca désigne le GetProperty ?

En gros, la réflexion d'une manière générale est lente (GetProperty, GetMethod, ...) même s'il existe des moyens de contournement, notamment via les délégués.

Pour ce qui est de ta remarque générale, je suis d'accord .... mais il faut aussi voir le cout de ce refactoring (et de tous les tests à refaire qui vont avec), des délais imposés, des dispos des testeurs, etc ... Malheureusement on est pas toujours dans les situations idéales où l'on peut faire tout comme on aimerait, sinon j'aurais déjà opté pour la réécriture du code.

Crois moi, je sais très bien de quoi tu parles.
Mais il aussi prendre en compte dans le calcul que ce problème "basique" t'en causera d'autre à l'avenir. Et que refactoriser le code de temps en temps t'évitera bien des désagréments si l'application a encore de longs jours devant elle.

[Loko]

bonjour

J'ai donc créé une interface qui impose des propriétés nommées "dateDeb" et "dateFin", entre autres.

J'ai écris une méthode de controle de dates qui prend en paramètre une liste d'objets implémetant cette interface :

Code :

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

1
2
public static Boolean CheckDates ( List<IIsDateCheckable> liste, bool pAllowStartEqualsEnd, bool pAllowOverlap, bool pAllowHolesInDates, bool pAllowInsertBefore)
                { ...

J'ai une erreur lorsque je veux appeler cette méthode avec une liste d'objets qui pourtant implémentent bien l'interface :

Opera.BL.ControleurDates.CheckDates(TSession.Instance.LiensUsinePF, ...

Argument 1: cannot convert from 'System.Collections.Generic.List<Opera.DTO.Modifications.MdlModificationLiensUsinePF>' to 'System.Collections.Generic.List<Opera.BL.IIsDateCheckable>'

J'ai essayé avec un cast, comme ceci :

Code :

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

CheckDates((List<IIsDateCheckable>)TSession.Instance.LiensUsinePF,

mais le cast n'est pas accepté.

Est ce que j'ai oublié qqchose, ou bien est ce que l'interface est une fausse bonne idée ?

Merci