Dupliquer possible:
C #: champs publics versus propriétés automatiquesDupliquer? Je crois que non:
Cette question est pas la même chose que "Pourquoi Utiliser des propriétés au lieu de public Field". Une propriété avec un spécifié getter et setter est très différent qu'un domaine public. Ma question était, est une propriété SANS un getter et passeur, différent.
Avec la capacité quelque peu récente d'avoir des getters et des setters vides, quel est l'avantage de les utiliser au lieu de simplement déclarer une variable de membre public?
Exemple:
public string MyProperty
{
get;
set;
}
contre:
public string MyProperty;
Un mot: héritage.
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 ne 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'héritage, les points soulignés dans les autres réponses (comme la visibilité) constituent également un énorme avantage 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 string 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
{
string 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:
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 à 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'objet, de l'état, en évitant la corruption et les utilisations abusives en appelant du code.
Vous pouvez marquer des propriétés avec des attributs qui ne sont pas disponibles sur les membres. Certains attributs ne s'appliquent qu'aux champs de l'espace de noms DataContract qui affecte la sérialisation, l'attribut ne peut pas être appliqué aux champs, etc.
Certes, rien n'empêche techniquement l'utilisation de ces attributs sur les membres, mais néanmoins, ils ne fonctionnent que sur les propriétés.