Bonjour à tous,
une des nouveautés de C# 3.0 est les propriétés auto-implémenté :
A la compilation, le compilateur crée des membres privés correspondant.Code:public int MyProperty {get;set;}
Pourquoi ne pas utiliser un membre publique dans ce cas?
Version imprimable
Bonjour à tous,
une des nouveautés de C# 3.0 est les propriétés auto-implémenté :
A la compilation, le compilateur crée des membres privés correspondant.Code:public int MyProperty {get;set;}
Pourquoi ne pas utiliser un membre publique dans ce cas?
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
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
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 MSILCitation:
Envoyé par Guulh