Pourquoi des propriétés get set vides au lieu d’utiliser une variable de membre public?

Un mot: inheritance.

Les propriétés sont héritables alors que les champs ne le sont pas. Vous pouvez utiliser des champs dans une classe héritée, mais vous ne pouvez pas modifier leur comportement en les rendant virtuels.

Ainsi:

 public class Foo { public virtual int MyField = 1; // Nope, this can't public virtual int Bar {get; set; } } public class MyDerive : Foo { public override MyField; // Nope, this can't public override int Bar { get { //do something; } set; } } 

Edit: Outre le fait de l’inheritance, les points soulignés dans les autres réponses (comme la visibilité) constituent également un avantage énorme des propriétés par rapport aux champs.

Une chose que vous pouvez faire avec des propriétés que vous ne pouvez pas faire avec des champs est de limiter la visibilité pour un setter ou un getter:

 public ssortingng MyProperty { get; private set; } 

Quelque chose que j’utilise beaucoup.

Et quelque chose (plus puissant) que vous ne pouvez pas faire avec les champs est de les définir dans une interface. Supposons que vous souhaitiez qu’une interface nécessitant la mise en oeuvre de classes ait une certaine propriété:

 public interface MyInterface { ssortingng MyProperty { get; } } 

Notez qu’il n’est pas nécessaire d’avoir un passeur ici. Il appartient entièrement aux classes d’implémenter de déterminer comment elles doivent définir MyProperty .

Les champs ne peuvent pas être exposés dans les interfaces. Et la propriété automatique peut être changée en une propriété “normale” à tout moment si nécessaire, sans modification de la signature et de l’interface de la classe.

En général, les champs sont considérés comme un détail d’implémentation, ce qui peut changer dans les futures versions du code. Par conséquent, vous devez exposer les données via des méthodes et des propriétés, laissant ainsi le champ libre aux modifications internes qui n’affecteront pas le code utilisant la classe.

Une propriété vous offre plusieurs avantages par rapport à un simple domaine public:

• vous pouvez contrôler si la propriété est en lecture seule, en écriture seule ou en lecture / écriture
• vous pouvez masquer l’implémentation réelle (peut-être que vous voulez faire plus que simplement définir une valeur dans le setter)
• lors de l’utilisation de la liaison de données (par exemple dans ASP.NET), vous devrez utiliser des propriétés (ne fonctionne pas avec les champs)

Couplage étroit vient à l’esprit. L’utilisation de champs publics supprime la couche d’abstraction rendue disponible par l’utilisation de propriétés. L’utilisation de champs et de propriétés privés masque l’implémentation des autres classes et permet de les isoler (classes externes) chaque fois qu’une modification est nécessaire.

N’oubliez pas non plus que vous faites référence à des propriétés implémentées automatiquement, ce qui amène le compilateur à créer le champ de sauvegarde pour vous au lieu de devoir créer manuellement le champ de sauvegarde (privé) pour chaque propriété de votre classe.

L’idée est de gérer les valeurs à l’intérieur de l’object, de l’état, en évitant la corruption et les abus en appelant du code.

Vous pouvez marquer des propriétés avec des atsortingbuts qui ne sont pas disponibles sur les membres. Certains atsortingbuts ne s’appliquent qu’aux champs de l’espace de noms DataContract qui affecte la sérialisation, l’atsortingbut ne peut pas être appliqué aux champs, etc.

Certes, rien n’empêche techniquement l’utilisation de ces atsortingbuts sur les membres, mais néanmoins, ils ne fonctionnent que sur les propriétés.