Y a-t-il d'autres avantages, ou peut-être des inconvénients de la "nouvelle" façon de définir les propriétés?

Question

Y a-t-il d'autres avantages à la «nouvelle» méthode plus courte de gestion des propriétés, à part des avantages de performances plus proches du code, une utilisation moindre de la mémoire, etc.?

Une écriture

public string StrVariable { get; set;} 

Plutôt que

private string strVariable; 

public string StrVariable 
{ 
    set 
    { 
     strVariable = value; 
    } 
    get 
    { 
     return strVariable; 
    } 
} 

Et sont-il des inconvénients - certains soutiendraient peut-être le code est moins lisible, moins explicite?

Answer 1

Heres a link you may find useful.

Answer 2

Un inconvénient que je peux voir est que si vous voulez faire quelque chose d'autre dans les get/set routines. Incrémenter un compteur ou quelque chose de ce genre. Peut-être valider l'entrée si vous ne l'avez pas déjà fait.

Answer 3

Un grand inconvénient dans un scénario spécifique - vous perdez le contrôle du nom de champ. Cela peut sembler insignifiant, mais is a big problem si vous utilisez la sérialisation binaire (via BinaryFormatter).

Autres choses: cependant,

• ils ne peuvent pas être readonly au niveau du terrain
• pour struct s vous devez appeler : this() dans les constructeurs personnalisés

Ils font, font un travail fantastique dans 99% des cas - ils expriment le code proprement, tout en permettant d'ajouter des détails d'implémentation supplémentaires plus tard (en basculant vers des champs explicites) sans casser le code appelant (sauf pour les points ci-dessus).

Answer 4

Les propriétés de collection sont également un problème. Ils ne sont pas initialisés avec Autoproperties.

Exemple:

public class foo 
{ 
    public List<String> S1 { get; set; } 

    private List<string> s = new List<string>(); 
    public List<String> S2 
    { 
     get { return s;} 
     set { s = value; } 
    } 
} 

foo f = new foo(); 
f.S1.Add("thing"); 
f.S2.Add("thing"); 

f.S1.Add bomberez à une exception nullref.