Discussion :

[Aurazed]

Bonjour à tous,

une des nouveautés de C# 3.0 est les propriétés auto-implémenté :

Code :

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

public int MyProperty {get;set;}

A la compilation, le compilateur crée des membres privés correspondant.

Pourquoi ne pas utiliser un membre publique dans ce cas?

[Guulh]

Parce qu'à l'avenir, si tu veux faire des traitements particuliers dans le get / set; il faudrait que tu changes ton champ public en propriété publique, ce qui est un breaking change pour les utilisateurs de ta classe.

cf ce thread : http://www.developpez.net/forums/sho...&highlight=set

[Pol63]

tant qu'il n'y a pas de reflection ou autre truc dans le genre, changer une variable en propriété ne pose guère de problème à mon avis

[Guulh]

Pour des variables de type internal, oui, ça pose pas de problèmes, puisqu'il n'y a pas de lien d'une assembly externe vers la propriété / le champ en question (pour peu que personne n'est fait de hack douteux à base de réflexion pour choper des variables privées / protégées / internes).

Quand tu codes une bibliothèque utilisée par d'autres projets / d'autres équipes, ça peut mettre le boxon. cf le thread dont j'ai mis en lien.

[tomlev]

Pour des variables de type internal, oui, ça pose pas de problèmes, puisqu'il n'y a pas de lien d'une assembly externe vers la propriété / le champ en question (pour peu que personne n'est fait de hack douteux à base de réflexion pour choper des variables privées / protégées / internes).

Quand tu codes une bibliothèque utilisée par d'autres projets / d'autres équipes, ça peut mettre le boxon. cf le thread dont j'ai mis en lien.

Même sans réflexion, ça fout la zone : un assembly qui utilise cette bibliothèque ne fonctionnera plus si le champ est transformé en propriété. Même s'il n'y a pas de code à changer, il faudra au moins recompiler : l'accès à une propriété, pour le CLR, est un appel de méthode, contrairement à l'accès à un champ. Ca ne génère pas les mêmes instructions MSIL