Discussion :

[jeanbonpuree]

Bonjour

Venant du C++, je me demande quels sont les intérêts des propriétés par rapport rapport à des accesseurs/mutateurs fait à la main ?

Perso, je ne trouve pas que cela soit plus rapide à écrire et que la lisibilité en soit augmentée)

[leSeb]

En effet, une propriété remplace les deux méthodes accesseurs/modifieurs. Le contenu sera le même c'est juste la forme qui change.

Cependant l'utilisation de propriétés est indispensable pour faire du Binding par exemple. Je ne sais pas si elles sont indispensables dans d'autres cas, mais c'est au moins un exemple de l'intérêt des propriétés.

[tomlev]

Perso, je ne trouve pas que cela soit plus rapide à écrire et que la lisibilité en soit augmentée)

Au niveau de la déclaration, ça ne change effectivement pas grand chose, sinon que le getter et le setter sont clairement associés.

Par contre, au niveau de l'utilisation, c'est plus intuitif d'écrire x.Name = "toto" que x.SetName("toto"), enfin je trouve...

Ca a aussi l'avantage de clairement identifier la propriété en tant que telle, ce qui ne saute pas forcément aux yeux avec une paire de méthodes.

Et en plus, depuis les propriétés auto-implémentées, tu peux écrire ça :

Code :

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

public string Name { get; set; }

Qui est en fait équivalent à ça :

Code :

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

1
2
3
4
5
6
private string _name;
public string Name
{
    get { return _name; }
    set { _name = value; }
}

Et là pour le coup ça fait gagner du temps...

[jeanbonpuree]

....
Cependant l'utilisation de propriétés est indispensable pour faire du Binding par exemple. Je ne sais pas si elles sont indispensables dans d'autres cas, mais c'est au moins un exemple de l'intérêt des propriétés.

Ah, ok, je vois. Une normalisation de présentation en quelques sorte.

@tomlev
Oui, je reconnais que dans le cas de l'auto implémentation c'est plus rapide mais hormis le get, faire du set sans un contrôle de valeurs ou autres vérifications, je dirais que (quitte à faire hurler les loups ), autant rendre le champs public.
: patapé :

[youtpout978]

Tu peux facilement changer l'accessibilité des accesseurs:

Code :

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

public string Name { get; private set; }

ou même supprimer un des accesseurs

[tomlev]

Oui, je reconnais que dans le cas de l'auto implémentation c'est plus rapide mais hormis le get, faire du set sans un contrôle de valeurs ou autres vérifications, je dirais que (quitte à faire hurler les loups ), autant rendre le champs public.

Non, justement. Bien sûr, fonctionnellement ça revient au même, mais il y a quand même de bonnes raisons d'utiliser une propriété plutôt qu'un champ
- un champ, c'est la façon dont une donnée est stockée : c'est donc un détail d'implémentation, qui ne devrait donc pas être publiquement visible (encapsulation)
- d'ailleurs une interface peut déclarer des propriétés, mais pas des champs
- suppose que tu crées une librairie avec une classe C qui expose un champ X, et que des programmes utilisent ta librairie. Si un jour tu décides que tu as besoin de contrôler les valeurs assignées à X, tu es obligé de transformer le champ en propriété ; tu changes donc l'interface publique de la classe, et les programmes qui utilisaient la lib doivent donc être recompilés. Alors que si tu avais dès le départ utilisé une propriété, tu en aurais juste changé l'implémentation, sans toucher à l'interface publique ; dans ce cas tu aurais pu juste remplacer la DLL, sans toucher aux programmes qui en dépendent.

Plus de détails dans cet article : http://tlevesque.developpez.com/tuto...t-importantes/

[jeanbonpuree]

@youtpout978
Oui, je reconnais une facilité et une rapidité de mise en oeuvre qui en plus est d'une certaine façon "standardisée" et qui incite à de la "bonne programmation".

@tomlev
Justement, c'est à la suite de la lecture de cet article dont tu mets le lien que je me suis décidé à poser ma question initiale (ma remarque sur le champ public était une boutade). Car en début d'article on peut lire:

Il vaut mieux être clair sur le fait que cet article n'aborde pas la question de savoir si quelque chose doit être une méthode ou une propriété. Ce n'est pas toujours une décision évidente, et une discussion sur les mérites de l'une ou de l'autre serait intéressante mais détournerait l'attention de l'objet de cet article.

Et en fait, ma question portait là-dessus et je vais la reformuler autrement:
Si au lieu d'écrire mon propre mutateur pour affecter une valeur à mon champ privé, j'utilise une propriété, quelles différences y aura t-il dans le code et son traitement (le code sera t-il plus optimisé, sera t-il d'office "inline"...)
Je voulais savoir aussi en gros, par comparaison avec le C++, ce qui avait conduit et justifié à ce changement.
C'est juste par curiosité.

[Babyneedle]

Et en fait, ma question portait là-dessus et je vais la reformuler autrement:
Si au lieu d'écrire mon propre mutateur pour affecter une valeur à mon champ privé, j'utilise une propriété, quelles différences y aura t-il dans le code et son traitement (le code sera t-il plus optimisé, sera t-il d'office "inline"...)
Je voulais savoir aussi en gros, par comparaison avec le C++, ce qui avait conduit et justifié à ce changement.
C'est juste par curiosité.

La relation entre le binaire d'exécution et le code source est différente. En C++, le code est compilé. En C#, le code est d'abord interprété, puis compilé.

Utiliser des facilités ou du code plus basique devrait en principe générer le même code compilé, au même titre que la presque totalité du code vb.net va générer le même binaire que son équivalent C#.

Et je trouve ironique que tu mentionnes C++ et les facilités alors que le nom même du langage est le porte étendard d'une facilité: l'incrémenteur '++'. Que tu écrives 'x = x + 1;' ou 'x++', ça va donner le même binaire, non?

[tomlev]

En C#, le code est d'abord interprété, puis compilé.

Ah bon ?
C'est plutôt le contraire ; il est d'abord compilé en langage intermédiaire (IL, similaire dans le principe au bytecode Java), et ce code IL est ensuite "interprété" par le CLR (machine virtuelle). En réalité ce n'est pas tout à fait de l'interprétation, c'est un peu plus subtil que ça : lors de la première exécution d'une méthode, celle-ci est compilé en code natif directement exécutable par le CPU. Donc en gros, c'est plutôt une double compilation.

[jeanbonpuree]

@Babyneedle

Utiliser des facilités ou du code plus basique devrait en principe générer le même code compilé,

Ok, donc, c'est en fait les propriétés sont justes une commodité d'écriture qui a poussé les concepteurs à introduire cette notion.

au même titre que la presque totalité du code vb.net va générer le même binaire que son équivalent C#.

Ah oui? Ok. Je ne pensais pas de prime abord que pour la même fonctionnalité, le code intermédiaire généré à partir de vb serait le même que celui généré à partir de C#.

Et je trouve ironique que tu mentionnes C++ et les facilités

Euh..non là je ne comprends pas. Je n'ai pas parlé des facilités j'ai juste mentionné le C++ comme le langage auquel je me référais pour, je me cite: "Je voulais savoir aussi en gros, par comparaison avec le C++, ce qui avait conduit et justifié à ce changement." En tout cas, pas d'ironie voulue de ma part.

Que tu écrives 'x = x + 1;' ou 'x++', ça va donner le même binaire, non?

J'avoue que je n'ai jamais été voir le code objet généré mais je suppute que oui, encore que le résultat final doit dépendre du compilateur et de ses options d'optimisations.

[jouana]

Ah mon avis l'avantage se situe au niveau du databinding et de la lecture du code.

Le fait d'encapsuler de cette manière te permet de donner l'impression de manipuler des variables alors que derrière tu as des contrôles, ça rend le code un peu moins lourd en lecture.

Ensuite d'un langage à un autre (objet), le principe d'encapsulation reste le même.

Et c'est moins le bordel quand tu fais de la reflexion

[jeanbonpuree]

Ah mon avis l'avantage se situe au niveau du databinding et de la lecture du code.

Le fait d'encapsuler de cette manière te permet de donner l'impression de manipuler des variables alors que derrière tu as des contrôles, ça rend le code un peu moins lourd en lecture.

Ensuite d'un langage à un autre (objet), le principe d'encapsulation reste le même.

Et c'est moins le bordel quand tu fais de la reflection

Effectivement, leSeb m'a parlé de cela:

Cependant l'utilisation de propriétés est indispensable pour faire du Binding par exemple. Je ne sais pas si elles sont indispensables dans d'autres cas, mais c'est au moins un exemple de l'intérêt des propriétés.

.

Je jetterais un oeil à tout cela. Merci.

[jouana]

Quand je parle de reflexion, je parle de ça http://msdn.microsoft.com/fr-fr/libr...(v=vs.90).aspx

Pour ce que ça intéresse

[GuruuMeditation]

Si vous avez l'occasion de lire CLR via C# (que je conseille), vous allez voir Jeffrey Richter démolir les propriétés. Je ne suis pas trop d'accord avec lui ce sur point là, mais c’est toujours intéressant de lire un avis différent. Surtout quand ça vient d'une bête en C#.