Quelle est la différence entre un champ et une propriété?

Les propriétés exposent des champs. Les champs doivent (presque toujours) restr privés à une classe et être accessibles via les propriétés get et set. Les propriétés fournissent un niveau d’abstraction vous permettant de modifier les champs sans affecter la manière dont ils sont utilisés par votre classe.

public class MyClass { // this is a field. It is private to your class and stores the actual data. private ssortingng _myField; // this is a property. When accessed it uses the underlying field, // but only exposes the contract, which will not be affected by the underlying field public ssortingng MyProperty { get { return _myField; } set { _myField = value; } } // This is an AutoProperty (C# 3.0 and higher) - which is a shorthand syntax // used to generate a private field for you public int AnotherProperty{get;set;} } 

@Kent souligne que les propriétés ne sont pas obligées d’encapsuler des champs, qu’elles peuvent effectuer un calcul sur d’autres champs ou servir à d’autres fins.

@GSS signale que vous pouvez également faire d’autres logiques, telles que la validation, lorsqu’une propriété est accessible, une autre fonctionnalité utile.

Les principes de programmation orientés object disent que le fonctionnement interne d’une classe doit être caché du monde extérieur. Si vous exposez un champ, vous exposez essentiellement l’implémentation interne de la classe. Par conséquent, nous intégrons des champs avec des propriétés (ou des méthodes dans le cas de Java) pour nous permettre de modifier l’implémentation sans casser le code en fonction de nous. Voir comme nous pouvons mettre de la logique dans la propriété nous permet également d’effectuer une logique de validation, si nécessaire. C # 3 a la notion peut-être déroutante d’autoproperties. Cela nous permet de définir simplement la propriété et le compilateur C # 3 générera le champ privé pour nous.

 public class Person { private ssortingng _name; public ssortingng Name { get { return _name; } set { _name = value; } } public int Age{get;set;} //AutoProperty generates private field for us } 

Une différence importante est que les interfaces peuvent avoir des propriétés mais pas des champs. Ceci, pour moi, souligne que les propriétés doivent être utilisées pour définir l’interface publique d’une classe tandis que les champs sont destinés à être utilisés dans le fonctionnement interne privé d’une classe. En règle générale, je crée rarement des champs publics et, de même, je crée rarement des propriétés non publiques.

Je vais vous donner quelques exemples d’utilisation de propriétés qui pourraient faire tourner les engrenages:

• Initialisation différée : Si vous avez une propriété d’un object qui est coûteuse à charger, mais à laquelle vous n’avez pas beaucoup access lors des exécutions normales du code, vous pouvez retarder son chargement via la propriété. Ainsi, la première fois qu’un autre module essaie d’appeler cette propriété, il vérifie si le champ sous-jacent est nul – si c’est le cas, il le fait et le charge, inconnu du module appelant. Cela peut grandement accélérer l’initialisation des objects.
• Dirty Tracking: Ce que j’ai appris de ma propre question ici sur StackOverflow. Lorsque j’ai beaucoup d’objects dont les valeurs peuvent avoir changé au cours d’une parsing, je peux utiliser cette propriété pour vérifier si elle doit être enregistrée dans la firebase database ou non. Si aucune propriété d’un object n’a été modifiée, l’indicateur IsDirty ne sera pas déclenché, et par conséquent, la fonctionnalité d’enregistrement l’ignorera lors de la détermination des éléments à restaurer dans la firebase database.

À l’aide de Propriétés, vous pouvez lancer un événement lorsque la valeur de la propriété est modifiée (aka. PropertyChangedEvent) ou avant que la valeur ne soit modifiée pour prendre en charge l’annulation.

Ceci n’est pas possible avec les champs (access direct à).

 public class Person { private ssortingng _name; public event EventHandler NameChanging; public event EventHandler NameChanged; public ssortingng Name{ get { return _name; } set { OnNameChanging(); _name = value; OnNameChanged(); } } private void OnNameChanging(){ EventHandler localEvent = NameChanging; if (localEvent != null) { localEvent(this,EventArgs.Empty); } } private void OnNameChanged(){ EventHandler localEvent = NameChanged; if (localEvent != null) { localEvent(this,EventArgs.Empty); } } } 

Étant donné que beaucoup d’entre eux ont expliqué les avantages et les inconvénients techniques des Properties et des Field , il est temps de passer aux exemples en temps réel.

1. Propriétés vous permet de définir le niveau d’access en lecture seule

Prenons le cas de dataTable.Rows.Count et dataTable.Columns[i].Caption . Ils proviennent de la classe DataTable et les deux sont publics. La différence de niveau d’access entre eux est que nous ne pouvons pas définir la valeur sur dataTable.Rows.Count mais nous pouvons lire et écrire dans dataTable.Columns[i].Caption . Est-ce possible à travers Field ? Non!!! Cela peut être fait avec Properties uniquement.

 public class DataTable { public class Rows { private ssortingng _count; // This Count will be accessable to us but have used only "get" ie, readonly public int Count { get { return _count; } } } public class Columns { private ssortingng _caption; // Used both "get" and "set" ie, readable and writable public ssortingng Caption { get { return _caption; } set { _caption = value; } } } } 

2. Propriétés dans PropertyGrid

Vous avez peut-être travaillé avec Button dans Visual Studio. Ses propriétés sont affichées dans le PropertyGrid comme Text , Name etc. Lorsque nous glissons et déposons un bouton, et lorsque nous cliquons sur les propriétés, il trouvera automatiquement la classe Button et filtre les Properties et le montrera dans PropertyGrid (où PropertyGrid ne sera pas affiché). Field même s’ils sont publics).

 public class Button { private ssortingng _text; private ssortingng _name; private ssortingng _someProperty; public ssortingng Text { get { return _text; } set { _text = value; } } public ssortingng Name { get { return _name; } set { _name = value; } } [Browsable(false)] public ssortingng SomeProperty { get { return _someProperty; } set { _someProperty= value; } } 

Dans PropertyGrid , les propriétés Name et Text seront affichées, mais pas SomeProperty . Pourquoi??? Parce que les propriétés peuvent accepter des atsortingbuts . Il ne s’affiche pas dans le cas où [Browsable(false)] est faux.

3. Peut exécuter des instructions dans les propriétés

 public class Rows { private ssortingng _count; public int Count { get { return CalculateNoOfRows(); } } public int CalculateNoOfRows() { // Calculation here and finally set the value to _count return _count; } } 

4. Seules les propriétés peuvent être utilisées dans la source de liaison

Binding Source nous aide à diminuer le nombre de lignes de code. Fields ne sont pas acceptés par BindingSource . Nous devrions utiliser les Properties pour cela.

5. Mode de débogage

Considérez que nous utilisons Field pour conserver une valeur. À un moment donné, nous devons déboguer et vérifier où la valeur devient nulle pour ce champ. Il sera difficile à faire lorsque le nombre de lignes de code est supérieur à 1000. Dans de telles situations, nous pouvons utiliser Property et définir le mode de débogage dans Property .

  public ssortingng Name { // Can set debug mode inside get or set get { return _name; } set { _name = value; } } 

DIFFERENCES – UTILISATIONS (quand et pourquoi)

Un champ est une variable qui est déclarée directement dans une classe ou une structure. Une classe ou une structure peut avoir des champs d’instance, des champs statiques ou les deux. En règle générale, vous devez utiliser des champs uniquement pour les variables ayant une accessibilité privée ou protégée . Les données que votre classe expose au code client doivent être fournies via des méthodes, des propriétés et des indexeurs. En utilisant ces constructions pour un access indirect aux champs internes, vous pouvez vous prémunir contre les valeurs d’entrée non valides.

Une propriété est un membre qui fournit un mécanisme flexible pour lire, écrire ou calculer la valeur d’un champ privé. Les propriétés peuvent être utilisées comme des membres de données publiques, mais ce sont en fait des méthodes spéciales appelées accesseurs . Cela permet d’accéder facilement aux données tout en favorisant la sécurité et la flexibilité des méthodes . Les propriétés permettent à une classe d’exposer une manière publique d’obtenir et de définir des valeurs, tout en masquant le code d’implémentation ou de vérification. Un accesseur de propriété get est utilisé pour renvoyer la valeur de la propriété et un accesseur d’ensemble est utilisé pour atsortingbuer une nouvelle valeur.

Les propriétés ont l’avantage principal de vous permettre de modifier la façon dont les données d’un object sont accédées sans casser son interface publique. Par exemple, si vous devez append une validation supplémentaire ou modifier un champ stocké en un calcul, vous pouvez le faire facilement si vous avez initialement exposé le champ en tant que propriété. Si vous venez d’exposer un champ directement, vous devrez alors changer l’interface publique de votre classe pour append la nouvelle fonctionnalité. Ce changement briserait les clients existants, les obligeant à être recompilés avant de pouvoir utiliser la nouvelle version de votre code.

Si vous écrivez une bibliothèque de classes conçue pour une consommation étendue (comme le .NET Framework, utilisé par des millions de personnes), cela peut poser problème. Cependant, si vous écrivez une classe utilisée en interne dans une petite base de code (disons <= 50 K lignes), ce n'est vraiment pas grave, car personne ne serait affecté négativement par vos modifications. Dans ce cas, il ne s'agit que de préférences personnelles.

En arrière-plan, une propriété est compilée en méthodes. Ainsi, une propriété Name est compilée dans get_Name() et set_Name(ssortingng value) . Vous pouvez le voir si vous étudiez le code compilé. Il y a donc une très légère surcharge de performances lors de leur utilisation. Normalement, vous utiliserez toujours une propriété si vous exposez un champ à l’extérieur et vous l’utiliserez souvent en interne si vous devez valider la valeur.

Les propriétés prennent en charge l’access asymésortingque, c’est-à-dire que vous pouvez avoir un getter et un setter ou un seul des deux. De même, les propriétés prennent en charge l’accessibilité individuelle pour getter / setter. Les champs sont toujours symésortingques, c.-à-d. Que vous pouvez toujours obtenir et définir la valeur. L’exception à ceci est les champs en lecture seule qui ne peuvent évidemment pas être définis après l’initialisation.

Les propriétés peuvent durer très longtemps, ont des effets secondaires et peuvent même générer des exceptions. Les champs sont rapides, sans effets secondaires et ne jettent jamais d’exceptions. En raison des effets secondaires, une propriété peut retourner une valeur différente pour chaque appel (comme cela peut être le cas pour DateTime.Now, c.-à-d. DateTime.Now n’est pas toujours égal à DateTime.Now). Les champs renvoient toujours la même valeur.

Les champs peuvent être utilisés pour les parameters out / ref, les propriétés peuvent ne pas l’être. Les propriétés prennent en charge une logique supplémentaire – cela pourrait notamment être utilisé pour mettre en œuvre un chargement différé.

Les propriétés prennent en charge un niveau d’abstraction en encapsulant ce que cela signifie pour obtenir / définir la valeur.

Utilisez les propriétés dans la plupart des cas, mais essayez d’éviter les effets secondaires.

Lorsque vous voulez que votre variable privée (champ) soit accessible à l’object de votre classe à partir d’autres classes, vous devez créer des propriétés pour ces variables.

Par exemple, si j’ai des variables nommées “id” et “name” qui sont privées mais il peut y avoir une situation où cette variable est nécessaire pour une opération de lecture / écriture en dehors de la classe. Dans cette situation, la propriété peut m’aider à obtenir la lecture / écriture de cette variable en fonction du get / set défini pour la propriété. Une propriété peut être un readonly / writeonly / readwrite les deux.

voici la démo

 class Employee { // Private Fields for Employee private int id; private ssortingng name; //Property for id variable/field public int EmployeeId { get { return id; } set { id = value; } } //Property for name variable/field public ssortingng EmployeeName { get { return name; } set { name = value; } } } class MyMain { public static void Main(ssortingng [] args) { Employee aEmployee = new Employee(); aEmployee.EmployeeId = 101; aEmployee.EmployeeName = "Sundaran S"; } } 

La deuxième question ici, “quand utiliser un champ au lieu d’une propriété?”, N’est que brièvement abordée dans cette autre réponse et est- ce un peu celle-là aussi , mais pas vraiment de manière détaillée.

En général, toutes les autres réponses sont axées sur une bonne conception: préférez exposer les propriétés aux champs d’exposition. Bien que vous ne vous trouviez probablement pas régulièrement en train de dire “wow, imaginez à quel point les choses seraient pires si j’en avais fait un champ plutôt qu’une propriété”, il est tellement plus rare de penser “wow, Dieu merci, j’ai utilisé un champ ici au lieu d’une propriété. ”

Mais il y a un avantage que les champs ont sur les propriétés, et c’est leur capacité à être utilisés comme parameters “ref” / “out”. Supposons que vous ayez une méthode avec la signature suivante:

 public void TransformPoint(ref double x, ref double y); 

et supposons que vous souhaitiez utiliser cette méthode pour transformer un tableau créé comme ceci:

 System.Windows.Point[] points = new Point[1000000]; Initialize(points); 

Voici le moyen le plus rapide de le faire, puisque X et Y sont des propriétés:

 for (int i = 0; i < points.Length; i++) { double x = points[i].X; double y = points[i].Y; TransformPoint(ref x, ref y); points[i].X = x; points[i].Y = y; } 

Et ça va être très bien! À moins que vous ayez des mesures qui prouvent le contraire, il n'y a aucune raison de jeter une puanteur. Mais je crois que ce n'est pas garanti techniquement aussi vite:

 internal struct MyPoint { internal double X; internal double Y; } // ... MyPoint[] points = new MyPoint[1000000]; Initialize(points); // ... for (int i = 0; i < points.Length; i++) { TransformPoint(ref points[i].X, ref points[i].Y); } 

En faisant certaines mesures moi-même, la version avec des champs prend environ 61% du temps en tant que version avec des propriétés (.NET 4.6, Windows 7, x64, mode de publication, aucun débogueur attaché). Plus la méthode TransformPoint coûteuse, moins la différence devient nette. Pour répéter cela vous-même, lancez la première ligne commentée et non commentée.

Même s'il n'y avait aucun avantage en termes de performances pour ce qui précède, il existe d'autres endroits où l'utilisation des parameters ref et out peut être bénéfique, par exemple lors de l'appel de la famille de méthodes Interlocked ou Volatile . Note: Au cas où cela serait nouveau pour vous, Volatile est essentiellement un moyen d'obtenir le même comportement que celui fourni par le mot-clé volatile . En tant que tel, comme volatile , il ne résout pas comme par magie tous les problèmes de sécurité des threads, comme son nom l'indique.

Je ne veux certainement pas paraître comme si je préconisais que tu ailles "oh, je devrais commencer à exposer des champs plutôt que des propriétés". Le fait est que si vous avez besoin d'utiliser régulièrement ces membres dans des appels prenant des parameters "ref" ou "out", en particulier sur un élément qui pourrait être un simple type de valeur qui ne nécessitera probablement aucun élément de valeur ajoutée, un argument peut être fait.

De plus, les propriétés vous permettent d’utiliser la logique lors de la définition des valeurs.

Vous pouvez donc dire que vous souhaitez uniquement définir une valeur sur un champ entier, si la valeur est supérieure à x, sinon, lancez une exception.

Fonctionnalité vraiment utile.

Si vous envisagez d’utiliser des primitives de thread, vous êtes obligé d’utiliser des champs. Les propriétés peuvent casser votre code threadé. En dehors de cela, ce que cory a dit est correct.

(Cela devrait vraiment être un commentaire, mais je ne peux pas poster de commentaire, alors s’il-vous-plaît excusez si ce n’est pas approprié en tant que post).

Une fois, j’ai travaillé à un endroit où la pratique recommandée était d’utiliser des champs publics au lieu de propriétés lorsque la propriété équivalente def accédait à un champ, comme dans:

 get { return _afield; } set { _afield = value; } 

Leur raisonnement était que le domaine public pourrait être converti en propriété plus tard si nécessaire. Cela me semblait un peu étrange à l’époque. À en juger par ces messages, il semble que peu d’entre eux soient d’accord. Que pourriez-vous dire pour essayer de changer les choses?

Edit: je devrais append que toute la base de code à cet endroit a été compilée en même temps, donc ils ont peut-être pensé que changer l’interface publique des classes (en changeant un champ public en propriété) n’était pas un problème.

Cette page sur MSDN a une comparaison et des conseils sur lesquels utiliser lorsque:

https://msdn.microsoft.com/en-us/library/9d65as2e(v=vs.90).aspx

Les champs sont des variables membres ordinaires ou des instances membres d’une classe. Les propriétés sont une abstraction pour obtenir et définir leurs valeurs . Les propriétés sont également appelées accesseurs car elles permettent de modifier et de récupérer un champ si vous exposez un champ de la classe comme privé. En règle générale, vous devez déclarer vos variables membres privées, puis déclarer ou définir les propriétés correspondantes.

  class SomeClass { int numbera; //Field //Property public static int numbera { get; set;} } 

Les propriétés encapsulent des champs, vous permettant ainsi d’effectuer un traitement supplémentaire sur la valeur à définir ou à récupérer. Il est généralement excessif d’utiliser des propriétés si vous ne prévoyez pas de post-traitement ou de post-traitement sur la valeur du champ.

Techniquement, je ne pense pas qu’il y ait une différence, car les propriétés ne sont que des wrappers autour des champs créés par l’utilisateur ou créés automatiquement par le compilateur. Le but des propriétés est d’imposer l’encapsulation et d’offrir une fonctionnalité légère. Déclarer les champs comme publics est une mauvaise pratique, mais cela ne pose aucun problème.

IMO, Propriétés ne sont que les paires de fonctions / méthodes / interfaces “SetXXX ()” “GetXXX ()” que nous avons utilisées auparavant, mais elles sont plus concises et élégantes.

Traditionnellement, les champs privés sont définis par les méthodes getter et setter. Pour réduire le code, vous pouvez utiliser des propriétés pour définir des champs à la place.

quand vous avez une classe qui est “voiture”. Les propriétés sont la couleur, la forme ..

Où les champs as sont des variables définies dans le cadre d’une classe.

From Wikipedia – Programmation orientée object :

La programmation orientée object (OOP) est un paradigme de programmation basé sur le concept “d’objects”, qui sont des structures de données contenant des données, sous la forme de champs , souvent appelés atsortingbuts; et code, sous la forme de procédures, souvent appelées méthodes . (soulignement ajouté)

Les propriétés font en réalité partie du comportement d’un object, mais sont conçues pour donner aux consommateurs de l’object l’illusion / l’abstraction de travailler avec les données de l’object.

Les propriétés sont un type particulier de membre de classe. Dans les propriétés, nous utilisons une méthode Set ou Get prédéfinie. Elles utilisent des accesseurs à travers lesquels nous pouvons lire, écrire ou modifier les valeurs des champs privés.

Par exemple, prenons une classe nommée Employee , avec des champs privés pour name, age et Employee_Id. Nous ne pouvons pas accéder à ces champs en dehors de la classe, mais nous pouvons accéder à ces champs privés via des propriétés.

Pourquoi utilisons-nous des propriétés?

Rendre public le champ de la classe et l’exposer est risqué, car vous n’aurez aucun contrôle sur ce qui est assigné et renvoyé.

Pour comprendre cela clairement avec un exemple, prenons une classe d’élèves qui ont une identité, un mot de passe, un nom. Maintenant, dans cet exemple, un problème avec le domaine public

• L’identifiant ne doit pas être -ve.
• Le nom ne peut pas être défini sur null
• La note de passage doit être en lecture seule.
• Si le nom de l’étudiant est manquant, aucun nom ne doit être renvoyé.

Pour supprimer ce problème, nous utilisons la méthode Get et set.

 // A simple example public class student { public int ID; public int passmark; public ssortingng name; } public class Program { public static void Main(ssortingng[] args) { student s1 = new student(); s1.ID = -101; // here ID can't be -ve s1.Name = null ; // here Name can't be null } } 

Maintenant, nous prenons un exemple de méthode get et set

 public class student { private int _ID; private int _passmark; private ssortingng_name ; // for id property public void SetID(int ID) { if(ID<=0) { throw new exception("student ID should be greater then 0"); } this._ID = ID; } public int getID() { return_ID; } } public class programme { public static void main() { student s1 = new student (); s1.SetID(101); } // Like this we also can use for Name property public void SetName(string Name) { if(string.IsNullOrEmpty(Name)) { throw new exeception("name can not be null"); } this._Name = Name; } public string GetName() { if( string.IsNullOrEmpty(This.Name)) { return "No Name"; } else { return this._name; } } // Like this we also can use for Passmark property public int Getpassmark() { return this._passmark; } } 

Ma conception d’un champ est qu’un champ doit être modifié uniquement par son parent, donc la classe. Résultat la variable devient privée, alors pour pouvoir donner le droit de lire les classes / méthodes en dehors, je passe par le système de propriété avec seulement le Get. Le champ est ensuite récupéré par la propriété et en lecture seule! Si vous voulez le modifier, vous devez passer par des méthodes (par exemple le constructeur) et je trouve que grâce à cette façon de vous sécuriser, nous avons un meilleur contrôle sur notre code car nous “bridons”. One could very well always put everything in public so every possible case, the notion of variables / methods / classes etc … in my opinion is just an aid to the development, maintenance of the code. For example, if a person resumes a code with public fields, he can do anything and therefore things “illogical” in relation to the objective, the logic of why the code was written. It’s my point of view.

When i use a classic model private field / public readonly properties,for 10 privates fields i should write 10 publics properties! The code can be really big faster. I discover the private setter and now i only use public properties with a private setter. The setter create in background a private field.

That why my old classic programming style was:

 public class MyClass { private int _id; public int ID { get { return _id; } } public MyClass(int id) { _id = id; } } 

My new programming style:

 public class MyClass { public int ID { get; private set; } public MyClass(int id) { ID = id; } } 

The vast majority of cases it’s going to be a property name that you access as opposed to a variable name ( field ) The reason for that is it’s considered good practice in .NET and in C# in particular to protect every piece of data within a class, whether it’s an instance variable or a static variable (class variable) because it’s associated with a class.

Protect all of those variables with corresponding properties which allow you to define, set and get accessors and do things like validation when you’re manipulating those pieces of data.

But in other cases like Math class (System namespace), there are a couple of static properties that are built into the class. one of which is the math constant PI

par exemple. Math.PI

and because PI is a piece of data that is well-defined, we don’t need to have multiple copies of PI, it always going to be the same value. So static variables are sometimes used to share data amongst object of a class, but the are also commonly used for constant information where you only need one copy of a piece of data.

Additional info: By default, get and set accessors are as accessible as the property itself. You can control/ressortingct accessor accessibility individually (for get and set) by applying more ressortingctive access modifiers on them.

Exemple:

 public ssortingng Name { get { return name; } protected set { name = value; } } 

Here get is still publicly accessed (as the property is public), but set is protected (a more ressortingcted access specifier).

Properties are used to expose field. They use accessors(set, get) through which the values of the private fields can be read, written or manipulated.

Properties do not name the storage locations. Instead, they have accessors that read, write, or compute their values.

Using properties we can set validation on the type of data that is set on a field.

For example we have private integer field age on that we should allow positive values since age cannot be negative.

We can do this in two ways using getter and setters and using property.

  Using Getter and Setter // field private int _age; // setter public void set(int age){ if (age <=0) throw new Exception(); this._age = age; } // getter public int get (){ return this._age; } Now using property we can do the same thing. In the value is a key word private int _age; public int Age{ get{ return this._age; } set{ if (value <= 0) throw new Exception() } } 

Auto Implemented property if we don't logic in get and set accessors we can use auto implemented property.

When u se auto-implemented property comstacks creates a private, anonymous field that can only be accessed through get and set accessors.

 public int Age{get;set;} 

Abstract Properties An abstract class may have an abstract property, which should be implemented in the derived class

 public abstract class Person { public abstract ssortingng Name { get; set; } public abstract int Age { get; set; } } // overriden something like this // Declare a Name property of type ssortingng: public override ssortingng Name { get { return name; } set { name = value; } } 

We can privately set a property In this we can privately set the auto property(set with in the class)

 public int MyProperty { get; private set; } 

You can achieve same with this code. In this property set feature is not available as we have to set value to field directly.

 private int myProperty; public int MyProperty { get { return myProperty; } } 

Think about it : You have a room and a door to enter this room. If you want to check how who is coming in and secure your room, then you should use properties otherwise they won’t be any door and every one easily come in w/o any regulation

 class Room { public ssortingng sectionOne; public ssortingng sectionTwo; } Room r = new Room(); r.sectionOne = "enter"; 

People is getting in to sectionOne pretty easily, there wasn’t any checking

 class Room { private ssortingng sectionOne; private ssortingng sectionTwo; public ssortingng SectionOne { get { return sectionOne; } set { sectionOne = Check(value); } } } Room r = new Room(); r.SectionOne = "enter"; 

Now you checked the person and know about whether he has something evil with him