Discussion :

[PatStan17]

Contexte : C#, SQL Serveur, POO, Développement en couches


Bonjour , je me pose une question et j'ai besoin d'avis éclairés ...

Rien que du classique :

J'ai une classe métier avec ses propriétés ...dans cette classe j'ai une méthode qui est chargée de s'adresser à une classe DAL qui est chargée de lui envoyer les données provenant de ma BDD.

la voici en gros :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Public Bool Remplir(long Identifiant)
 
{
Tiers Personne = new Tiers();
Tiers DAL = new TiersDAL();
Personne = DAL.Envois(Identifiant);
 
m_NomTiers =  Personne.NomTiers
m_PrenomTiers = Personne.PrenomTiers
 ..etc
}

Je suis donc dans ma classe et j'ai mes propriétés :

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
Public String NomTiers
{
get
{
return m_NomTiers
}
set
{
m_NomTiers = value
}
}

A votre avis , dans ma méthode, quelle est la meilleure syntaxe :

celle-ci :

Code :

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

m_NomTiers =  Personne.NomTiers

ou celle-ci

Code :

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

this.NomTiers = Personne.NomTiers

Je sais que si j'utilise le mot this je passe par un éventuel control des données implémenté dans la propriété mais à par cela ?

Merci pour les avis d'experts


Patrick

[clenoir]

Bon je ne me prétends pas expert mais je tente une réponse quand même car je pense qu'il y a confusion dans ta demande.

C'est le fait de passer par NomTiers qui va déclencher éventuellement d'autres opérations définies dans le "set" de ta propriété NomTiers (pas le this).

Exemple si un jour tu veux t'amuser à lancer des évènements en cas de modification de la valeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Public String NomTiers
{
get
{
return m_NomTiers;
}
set
{
m_NomTiers = value;
OnNomTiersChanged(EventArgs.Empty);
}
}

Intuitivement j'aurais plutôt tendance à utiliser

Code :

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

this.m_NomTiers = Personne.NomTiers;

en fait car au moins je sais exactement ce que je modifie (sinon ça peut vite devenir un véritable enfer si on n'est pas très rigoureux).

Au passage j'utilise toujours "this" quand je le peux, d'abord pour voir immédiatement qu'il s'agit d'un élément de la classe (pour une question de clareté, et aussi parce que j'abuse de l'auto-complétion ), et également car je me dis que ça facilite sans doute le travail du compilateur de préciser directement que cet élément est présent dans la classe (après je me base sur mon intuition, ce n'est pas forcément exact).

[giova_fr]

+1

this.NomTiers = Personne.NomTiers

sera plus long que faire

m_NomTiers = Personne.NomTiers

vu que en un sens tu appelle la methode NomTiers (ca pointe sur NomTiers puis ca pointe sur son set), cela dit, on parle de perdre un pouillemme de temps, ca ne se sentirait que si tu devais le faire sur des milliers d'objets.

Comme le dit Clenoir, NomTiers te permet d'ajouter un comportement à ton get ou ton set, et/ou de totalement personnaliser la visibilité :

dans cet exemple, le set est private, et en plus déclenche un evenement.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Public String NomTiers
{
public get
{
return m_NomTiers;
}
private set
{
m_NomTiers = value;
if(NomTiersChanged != null)
NomTiersChanged(this, EventArgs.Empty);
 
}
}

en general, on dit qu'un objet externe ne doit JAMAIS modifier directement une propriété (m_mavar) mais doit passer par MaVar; ceci afin de pouvoir controler l'acces. en revanche, en interne, un objet devrait toujours modifier directement sa propriété (m_mavar) sauf quand on souhaite systematiquement ajouter un comportement lors de la mutation.

[PatStan17]

vos réponses m'éclairent ou confirme ce que mon bon sens (...si j'en ai un peu ) me disait ...

Je laisse la discusion ouverte ...si qqn veut ajouter qqchose

En tout cas ...merci

[Pol63]

j'ai encore un peu de mal à lire le c#, je fais du vb.net

mais j'ai l'impression que vous conseillez de setter la variable plutot que la propriété, et ce pour avoir plus de perf
certes c'est plus performant, mais à mon avis ca fait gagner genre une picoseconde donc c'est pas un argument valable

moi je serais plus pour setter la propriété, biensur ca dépend du cas, mais si on a du code dans le set qui vérifie telle ou telle chose ca ne sera pas exécuté en settant la variable, meme si à un instant T on a pas de code dans le set, ca peut changer dans le temps et donc y aura pas de modif à faire de partout
de plus ca permet de débugger, si on veut savoir quand la variable passe à telle valeur, on peut le coder dans le set avec un point d'arret, si la variable est tapée directement à certains endroits on ne pourra alors pas l'intercepter ...

EDIT je viens de tester : 1 millions de set 8ms en direct, 11ms en passant par la propriété, donc c'est pas de l'ordre de la picoseconde enfin c'est dérisoire quand meme

[PatStan17]

Il me semble aussi que c'est mieux de passer par la propriété que par la vairable ...le gain de performances est négligeable ...

Merci pour l'intérét porté à ma question



Patrick

[MetalGeek]

Salut,
personnellement j'aurais tendance à valoriser le champ directement, mais en fait ça dépend de l'usage que vous faites des propriétés : dans mon cas les propriétés sont quasiment toujours là pour être appelées par les autres types (encapsulation).
Si je dois effectuer des opérations spéciales avant de valoriser mon champ, je fais appel à une méthode utilitaire, du genre "this.SafeSetMyVariable(valeur)".

[clenoir]

mais j'ai l'impression que vous conseillez de setter la variable plutot que la propriété, et ce pour avoir plus de perf
certes c'est plus performant, mais à mon avis ca fait gagner genre une picoseconde donc c'est pas un argument valable

Je me sens concerné par le "vous", pourtant je n'ai pas avancé cet argument. Néanmoins je me dois tout de même de réagir car lorsque tu as fait ton test de différence de temps, tu n'as pas tenu compte des éventuels traitements supplémentaires qui peuvent être réalisés dans les properties et qui ne sont pas toujours utiles lorsque tu mets à jour un attribut.

De plus, je pense qu'il n'était pas très utile de faire ce test car si on imagine justement qu'aucun traitement supplémentaire n'est réalisé par les properties, la différence se sentirait plus à la compilation qu'à l'exécution non (quoique comme tu as constaté une différence tu me mets un doute là ) ?

Par contre je n'avais pas pensé à l'argument du debug : ça ne m'a jamais posé problème, mais c'est intéressant.

Sinon je suis allé décompiler les sources de dll comme System.dll ou mscorlib.dll, et... les deux solutions sont utilisées (parfois même dans la même classe, sans que je perçoive la logique qui a poussé à faire un accès direct ou via une property ) .

[Pol63]

il y a bien une différence de temps d'exécution même si rien de spécial n'est fait dans le set ...

[bacelar]

Moi, je ne mets jamais "this".
Si "this" rend le code plus clair, c'est que les noms sont très mals choisis.
Il ne faut pas oublier de respecter les règles de nommage de M$ qui permettent de facilement savoir s'il s'agit d'une constante, d'un membre privé, d'une propriété d'un Event etc..
Pas de m_ et consort, la notation hongroise à fait sont temps.

Pour l'utilisation de la propriété ou du champ, je ne vois pas pourquoi il doit avoir une règle absolue. Soit nous utilisons la propriété si nous avons besoin de déclencher du code associé soit le champ quand seule la valeur est pertinente. Donc les deux cas doivent se produire dans la même classe.

[clenoir]

Pol63 > Merci pour cette précision .

Bacelar >
Il est clair que l'utilisation de "this" ne dispense pas de respecter les conventions de nommage . Je trouve le "this" plus clair car j'ai la chance d'avoir un IDE qui me le met vraiment en valeur et car j'aime bien les couleurs (il peut aussi servir à différencier des éléments d'une classe dérivée par rapport à sa classe de base, mais utiliser les mêmes noms sans qu'il y ait override, je ne pense pas que ce soit très recommandé).
Mais j'avoue que ça me sert surtout par feinéantise pour lister rapidement tous les éléments de la classe (y compris les méthodes dont je n'ai pas le courage de chercher le nom correct).

Pour ce qui est du débat sur la propriété et le champ, je pense que ton raisonnement se tient (enfin, dans le cas particulier du constructeur les properties sont vraiment à éviter) mais la question ne se posait-elle pas justement lorsqu'on ne connait pas trop le contexte vers lequel ça risque d'évoluer ?

[Pol63]

+1 pour le this, ca filtre quand même l'intellisense et ca l'affiche plus rapidement