Différences entre les champs privés et les propriétés privées

Question

Quelle est la différence entre l'utilisation de propriétés privées et de champs privés ?

private String MyValue { get; set; }

// instead of

private String _myValue;

public void DoSomething()
{
   MyValue = "Test";

   // Instead of

   _myValue = "Test";
}

Y a-t-il un problème de performance ? ou simplement une convention de dénomination ?

Answer 1

Les propriétés privées vous permettent d'abstraire vos données internes de sorte que les modifications apportées à la représentation interne ne doivent pas affecter d'autres parties de votre implémentation, même dans la même classe. Les champs privés n'offrent pas cet avantage. Avec les propriétés automatiques en C# 3.0, je vois rarement la nécessité d'implémenter directement les champs -- privés ou publics.

Answer 2

Le grand avantage que vous pouvez tirer d'une propriété (privée, publique, ...) est qu'elle peut produire une valeur calculée par rapport à une valeur fixée. Par exemple

class Person { 
  private DateTime _birthday;
  private int _age { get { return (DateTime.Now - _birthday).TotalYears; }
}

L'avantage de ce modèle est qu'une seule valeur doit être mise à jour pour que les N autres valeurs reflètent le changement. Ceci est vrai pour les propriétés, quelle que soit leur accessibilité. Il n'y a pas d'avantage spécifique d'une propriété privée par rapport à une propriété non privée (autre que le fait qu'elle soit privée, bien sûr).

Answer 3

Il est rare que l'on veuille rendre une propriété privée. La disposition permettant à une propriété d'être privée n'est prévue que par souci d'exhaustivité. Et si votre propriété permet simplement d'obtenir/de définir la valeur du champ, il n'y a pas de différence de performance car elle sera très probablement intégrée par le compilateur JIT.

Answer 4

En dehors de ce qui a déjà été répondu, la performance, la symétrie et l'exhaustivité, il y a un cas valide que j'ai vu pour les propriétés privées au lieu d'un champ privé :

public class Item
{
    private Item _parent;
    private List<Item> _children;

    public void Add(Item child)
    {
        if (child._parent != null)
        {
            throw new Exception("Child already has a parent");
        }
        _children.Add(child);
        child._parent=this;
    }
}

Disons que nous ne voulons pas exposer Parent pour une raison quelconque, mais nous pourrions également vouloir faire des contrôles de validation. Un parent doit-il pouvoir être ajouté comme enfant à l'un de ses enfants ?

Pour résoudre ce problème, vous pouvez en faire une propriété et effectuer une vérification des références circulaires.

Answer 5

L'accès aux propriétés sera (fractionnellement) plus lent car il fera appel au getter/setter. L'avantage est que vous pouvez effectuer une validation des données, qui peut ensuite filtrer jusqu'aux héritiers si vous modifiez la propriété pour qu'elle soit protégée, par exemple.