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.

[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]

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