Discussion :

[StringBuilder]

Bonjour,

Déjà, pour être compréhensible, afin que tout le monde sache de quoi je parle (d'un article à l'autre, j'ai trouvé différents noms aux principes dont je parle, donc je préfère que tout le monde soit d'accord).

Attribut : "variable" de l'objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class test
{
    public int MonAttribut;
}

Propriété : couple de "méthodes" dédiées à l'accès d'un attribut (généralement privé) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
class test
{
    private int _monAttributPrivé;
 
    public int MaPropriété
    {
        get
        {
            return _monAttributPrivé;
        }
        set
        {
            _monAttributPrivé = value;
        }
    }
}

Les propriétés sont la suite logique des méthodes "SetAttribut()" et GetAttribut()" qu'on trouvait dans le code C++ autrefois.

Maintenant que les définitions sont données, les questions :

1) J'ai bon niveau désignation des deux concepts ?

2) J'ai bien compris la différence entre les deux, même si elle est parfois subtile :
- Dans l'exemple ci-dessus, je ne vois absolument aucune différence entre les deux concepts
- L'utilisation de "readonly" sur un attribut permet de reproduire le comportement une propriété avec uniquement un get.
- Ne reste donc que le cas des propriété avec uniquement un set, ainsi que celles avec des actions au niveau du set et/ou get
=> Pourtant, je vois de plus en plus de personnes écrire des propriétés avec cette syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class test
{
    int MaPropriété { get; set; }
}

Et là, je reste pantois.

Quel est l'intérêt d'utiliser une propriété plutôt qu'un attribut ? Puisqu'on n'a pas de corps aux get/set, et qu'en plus il n'y a pas d'attribut privé caché derrière (et donc un bordel pas possible le jour où on décide de mettre un corps aux get/set).

En effet, par exemple, les propriétés me servent habitellement à faire ce genre de choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
class Sequence
{
    int _currentValue = 1;
 
    public int NextValue
    {
        get
        {
            if (_currentValue == int.MaxValue) throw new Exception("Dépacement de capacité dans la séquence...");
            return _currentValue++;
        }
    }
 
    public int CurrentValue
    {
        get
        {
            return _currentValue;
        }
        set
        {
            if (value <= 0) throw new Exception("Une séquence ne fonctionne que sur l'interval [1,∞[");
            _currentValue = value;
        }
    }
}

C'est à dire avec une valeur ajoutée dans le get/set.

A quoi sert donc cette nouvelle syntaxe {get;set;}
=> Si par hasard un jour on a envie de faire une Propriété au lieu d'un attribut ?
Vu le changement de code nécessaire pour utiliser un attribut privé partout où les valeurs ajoutées au get/set ne devront pas être exploitées, je ne vois pas trop ce que ça change... D'autant qu'au niveau de l'appel dans le code, propriété ou attribut, c'est rigoureusement identique.

Quel wagon ais-je raté ?

[Max]

Salut.

1) J'ai bon niveau désignation des deux concepts ?

Non, et du coup ça te mélange les pinceaux pour la suite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
private int myField; // ceci est un champ
 
[Serializable] // ceci est un attribut
public int MyProperty { get; set; } // ceci est une propriété

Ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
private int myProperty; 
public int MyProperty {
    get { return this.myProperty; }
    set { this.myProperty = value; }
}

Et :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public int MyProperty { get; set; }

C'est exactement la même chose, seulement la deuxième version est autorisée depuis je ne sais plus quelle version du FW (3.0 je crois), c'est une forme de sucre syntaxique .

L'utilisation de la première écriture reste utile lorsque tu as un truc plus complexe à faire dans ton get et/ou set. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
private int myProperty; 
public int MyProperty {
    get { return this.myProperty; }
    set { this.myProperty = value < 0 ? 0 : value; }
}

En espérant que ça t'aide

[BenoitM]

A quoi sert donc cette nouvelle syntaxe {get;set;}

Simplement a être plus rapide

Le but est justement d'utiliser les bonnes pratiques.
Le jour ou tu devras changer pour X raison ta propriété , tu pourras le faire facilement
Si tu avais utilisé un attributs tu n'aurais pas pu

Si par hasard un jour on a envie de faire une Propriété au lieu d'un attribut ?

mais get;set; est une Propriété et non un champ

[Aeronia]

Personnellement je préfères me forcer à utiliser la "syntaxe" complète càd :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
private int myProperty; 
public int MyProperty {
    get { return this.myProperty; }
    set { this.myProperty = value; }
}

Ce qui se fait de toute façon très rapidement via un snippet.

Au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int MyProperty { get; set; }

Car comme l'as souligné en autre StringBuilder , cette manière de l'écrire demande tout simplement moins de temps de modification lorsque l'on a besoin d'implémenter des get/set conditionnés.

[StringBuilder]

Ce que je veux dire c'est que mettons la classe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Carre1
{
    public double Cote;
    public double Surface;
    public double Perimetre;
 
    public Carre(double cote)
    {
        Cote = cote;
        Surface = Math.Pow(double , 2D);
        Perimetre = cote * 4D;
    }
}

Et la classe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Carre2
{
    public double Cote {get;set}
    public double Surface {get;set}
    public double Perimetre {get;set}
 
    public Carre(double cote)
    {
        Cote = cote;
        Surface = Math.Pow(cote, 2D);
        Petimetre = cote * 4D;
    }
}

Maintenant, j'ai pour instruction de faire en sorte que si Cote, Surface ou Perimetre change, il faut que ça impacte immédiatement les deux autres propriétés.

Je vais donc faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
class Carre3
{
    private double _cote;
 
    public double Cote
    {
        get
        {
            return _cote;
        }
        set
        {
            _cote = value;
        }
    }
 
    public double Surface
    {
        get
        {
            return Math.Pow(_cote, 2f);
        }
        set
        {
            _cote = Math.Sqrt(_cote);
        }
    }
 
    public double Perimetre
    {
        get
        {
            return _cote * 4D;
        }
        set
        {
            _cote = value / 4D;
        }
    }
 
    public Carre(double cote)
    {
        _cote = cote;
    }
}

Comme on le voit, on a absolument le même nombre de lignes qui changent, et exactement la même structure publique.

Du coup je ne vois pas en quoi remplacer un champ par une propriété avec un get/set vide change quoique ce soit. Éventuellement, si on met un corps qui utilise une variable privée, ok, ça économise un peu de code par la suite. Mais avec un get/set vide, je ne vois pas du tout.

[sisqo60]

Bonjour,

Champs

Propriétés

tu peux aussi lever des évèvènement au changement de valeur d'une propriété etc..., mais pas directement avec un champs.

[StringBuilder]

Bonjour,

Champs

Propriétés

tu peux aussi lever des évèvènement au changement de valeur d'une propriété etc..., mais pas directement avec un champs.

Nan mais ça, je sais.

La question que je pose concerne justement l'utilisation de Propriété auto-implémentée : qu'est-ce que ça peut apporter par rapport à l'utilisation d'un champ ?
Mise à part qu'une personne a dit un jour "les champs ne devraient jamais être public, il faut utiliser des propriétés pour pouvoir valider les valeurs mise à jour à l'extérieur de la classe".
=> Dans ce cas, si on utilise des propriétés pour "pouvoir" valider les valeurs, je ne vois pas pourquoi on autorise un set vide. (idem pour le get)

[DonQuiche]

Attribut : "variable" de l'objet :
Propriété : couple de "méthodes" dédiées à l'accès d'un attribut (généralement privé)
1) J'ai bon niveau désignation des deux concepts ?

Les bonnes terminologies en C# sont "variable membre" et "propriété". Les attributs désignent autre chose (des métadonnées).

Quant à savoir si un attribut au sens UML correspond uniquement à une variable, ou à une variable ou une propriété indifféremment, c'est un autre débat dans lequel je ne plongerai pas.

- L'utilisation de "readonly" sur un attribut permet de reproduire le comportement une propriété avec uniquement un get.

Du point de vue externe à la classe, oui. Du point de vue interne, non, puisque la variable readonly ne peut être assignée que par le constructeur alors que la variable sous-jacente à une propriété readonly pourra l'être n'importe quand.
Cela affecte d'ailleurs les possibilités d'optimisation par le compilateur puisqu'il ne peut pas savoir si une propriété sans setter aura malgré tout une valeur constante.

La question que je pose concerne justement l'utilisation de Propriété auto-implémentée : qu'est-ce que ça peut apporter par rapport à l'utilisation d'un champ ?

Pour le reste... Il se trouve qu'en C# l'usage est d'avoir rarement des champs publics et de leur préférer des propriétés publiques à la place, vraisemblablement pour des raisons esthétiques. On peut choisir de procéder différemment. Cela dit deux arguments en faveur de l'usage systématique des propriétés publiques au lieu de champs publics :
* Certaines classes utilisant la réflexion ne considèrent que les propriétés (sérialisation XML par ex, bindings WPF dans les premières versions, etc) ou que les champs (sérialisation binaire).
* S'il est tout à fait possible de transformer un champ en propriété sans gêner la compilation, cela affectera les assemblys dépendantes qui n'auront pas été recompilées et évidemment tout procédé utilisant la réflexion. A contrario, si dès le départ on avait utilisé une propriété, on pourrait la modifier sans subir ces conséquences.

Puisqu'on n'a pas de corps aux get/set, et qu'en plus il n'y a pas d'attribut privé caché derrière (et donc un bordel pas possible le jour où on décide de mettre un corps aux get/set).

Il y a forcément une variable cachée derrière une propriété auto-implémentée, elle est générée par le compilateur.

[StringBuilder]

Merci DonQuiche, les deux * sont exactement la réponse que j'attendais.

Je ne me suis en effet jamais penché sur ces fonctionnalités de .NET
Mais ok, je prends bien notre et à l'avenir je préférerai utiliser des propriétés systématiquement.

En revanche, je pense passer systématiquement par un champ privé plutôt qu'un get/set vide, que je trouve sale et inutile.

[DonQuiche]

Content d'avoir satisfait tes interrogations.

En revanche, je pense passer systématiquement par un champ privé plutôt qu'un get/set vide, que je trouve sale et inutile.

Question de préférences, tu n'es pas le seul dans ce cas.
Cela dit, personnellement j'aime bien entasser les propriétés triviales en un gros bloc compact comme je le ferais pour des champs et les propriétés auto-implémentées font merveille pour ça.

[StringBuilder]

Il y a forcément une variable cachée derrière une propriété auto-implémentée, elle est générée par le compilateur.

Oui, mais vu qu'on ne peut pas la récupérer dans le code, l'intérêt est plutôt limité.

Si par exemple, le fait de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class Test
{
   public int propriete1 {get;set;}
   public string propriete2 {get;set;}
}

Générait automatiquement mettons une structure "BackingFields" privée comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class Test
{
   public int propriete1 {get;set;}
   public string propriete2 {get;set;}

   
   TestBackingFields _backingFields;

   struct TextBackingFields
   {
      int propriete1;
      string propriete2;
   }
   
}

Qu'on puisse ensuite appeler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
class Test
{
   public int propriete1 {get;set;}
   public string propriete2 {get;set;}
 
   TestBackingFields _backingFields;
 
   struct TextBackingFields
   {
      int propriete1;
      string propriete2;
   }
 
   public void FaitUnTruc(int a, string b)
   {
      _backingFields.propriete1 = a;
      _backingFields.propriete2 = b;
   }
}

=> Là, oui, je serais parfaitement convaincu de l'utilité des propriétés auto-implémentées. Mais là, je ne vois pas trop l'intérêt, mise à part faire croire au développeur qu'il développe proprement "ouais, t'as vu, j'ai plus un seul champ public !" alors que le programme est toujours autant exposé aux bugs à cause de l'absence de contrôle dans les accesseurs.

[DonQuiche]

Si par exemple, le fait de faire :
Générait automatiquement mettons une structure "BackingFields" privée comme suit :

Mais ça n'aurait aucun intérêt. Sones-tu aux performances ? Mais de toute façon le JIT supprimera l'appel à la propriété pour y substituer un appel au champ derrière.

Le seul cas où on aurait vraiment besoin du champ sous-jacent, ce serait parce qu'on a besoin de son adresse (via ref, , pour une bidouille unsafe ou parce que la propriété renvoie une structure mutable dont on voudrait modifier un champ : "MaPropriétéQuiRenvoieUneStructure.x = 10" ne compilera pas).

[BenoitM]

Il se trouve qu'en C# l'usage est d'avoir rarement des champs publics et de leur préférer des propriétés publiques à la place,

Non non pas en C# mais en POO
Les propritétés (get/set) sont une récommandation(obligation?) depuis longtemps que se soit en c++, java

L'utilité c'est que tu n'est jamais sur que tu ne devrais pas passer par une propriété plutot qu'un champ.
Si tu te rends compte X jours/mois après que tu ne dois pas accepter de somme négative, de champ plus long que X caractères, tu devras revoir tout ton programme alors que si tu avais utilisé des propriétés ceci aurait eu nettement moins d'impact

Donc pour eviter de se poser la question on utilise toujours des propriétés même si c'est (souvent) inutile.
Il vaut mieux un exces de prudence que l'inverse.

[StringBuilder]

Si tu te rends compte X jours/mois après que tu ne dois pas accepter de somme négative, de champ plus long que X caractères, tu devras revoir tout ton programme alors que si tu avais utilisé des propriétés ceci aurait eu nettement moins d'impact

Ça c'est pas vrai : transformer un champ en propriété, ça ne prends pas plus de temps que transformer une propriété auto-implémentée en propriété avec une implémentation manuelle.

Donc OK si t'as de la réflexion et de la sérialisation automatique, ce qui reste tout de même marginal, mais pour 99% des gens, t'as que quelques lignes à vérifier au sein de la classe dont le champ est transformé en méthode qu'il faut vérifier.
Le plus compliqué étant de déterminer si dans une méthode on doit utiliser la propriété ou le backfield : d'un point de vues performances, le backfield sera mieux, mais d'un point de vue fonctionnel, ça peut être très différent (si les accesseur font des actions en plus de simples contrôles)

[StringBuilder]

Mais ça n'aurait aucun intérêt.

Ben si, le jour où j'implémente manuellement mes accesseurs, alors j'ai déjà mon backfield près à l'emploi, et que j'ai déjà utilisé dans le reste de ma classe.

[BenoitM]

Ça c'est pas vrai : transformer un champ en propriété, ça ne prends pas plus de temps que transformer une propriété auto-implémentée en propriété avec une implémentation manuelle.

Euh je parle de la différence entre un champ directement accessible et d'un champ encapsuler via une property(get/set).
Et c'est parce que tu en C# que cette transformation n'a que peu d'impact.
En c++ tu dois creer des Getter et Setter (GetChamp1, SetChamp1)pour pouvoir encapsuler tes champs

Et il n'y aucune différence entre une Property et une Property auto implémenté. C'est juste pour épargner les petites mains du programmeur qui n'aime pas utilisé ca souris ou qui n'a pas trouvé le snippet :p

Donc je vois pas pourquoi tant de débat autour du sujet Property ou Property auto implémenté.C'est exatement la meme chose

Si tu n'aimes pas la synthaxe, suffit de pas l'utiliser

[StringBuilder]

Ben vu que c'est autant utilisé, j'imaginais qu'il y avait un avantage.

Mais je n'en vois pas, mise à part changer l'aspect des membres de la classe dans l'explorateur de classes

En revanche, je vais tâcher d'utiliser systématiquement des propriété dorénavant, chose que je ne faisais que lorsqu'il y avait une utilité fonctionnelle (ou technique).

[BenoitM]

Je suis pas sur que c'est tant utilisé. Que tu les vois souvent dans des exemples oui mais dans de vrais projets je suis moins convaincu.
Va falloir faire un sondage

[Guulh]

Ca m'épate qu'on puisse vouloir se passer volontairement des propriétés automatiques... Si on commence à dire qu'on veut garder des champs privés "parce que ça peut servir", alors autant remettre le constructeur par défaut "parce que ça peut servir", autant implémenter IDIsposable "parce que ça peut servir", autant définir explicitement add/remove sur les event pour la même raison

Donc, pourquoi les propriétés plutôt que les champs ?

• Parce qu'on ne peut pas définir de champ dans une interface
• parce qu'on ne peut pas rendre un champ virtuel
• parce que plein d'API faisant appel à la réflexion (sérialisation, binding, ...) ne gère que les properies et pas les champs
• parce que c'est un breaking change, comme l'a dit DonQuiche, et donc une lib B qui référence A ne marchera plus sans être recompilée si un champ de A devient une propriété
• parce que d'un point de vue perf, on s'en fout, c'est le jitter qui se chargera d'inlier tout ça
• parce que ça montre bien qu'une classe, en tant qu'unité d'encapsulation, ne donne jamais accès à son état interne sans se laisser la possibilité de valider/notifier/whatever
• Parce que ça normalise ce qu'expose une classe/une interface: des propriétés, des méthodes, des events, et c'est tout.
• Parce que c'est le standard, et que si chacun fait à sa sauce pour ce genre de choix consensuel, ça engendre un surcoût projet inutile en temps d'adaptation, refactoring, ...

Pourquoi les propriétés automatiques plutôt que les propriétés manuelles (dans le cas of course où on fait rien dans le get set)

• Moins verbeux!
• pas de problématique de convention de nommage (je mets un underscore? une minuscule? du hongrois?
• parce que l'intellisense n'est pas pollué à l'intérieur de la classe par deux fois plus de tokens que nécessaire

Sur ce

[Bluedeep]

Bonjour

Je n'ai pas tout lu, mais je vais rajouter une raison qui à mon sens justifie entiérement de ne pas utiliser les variables membres publiques en lieu et place des propriétés (sauf cas particulier, légers, un exemple typique étant tout ce qui hérite de EventArgs) :

- L'extraction d'interface.

En effet, il peut arriver (et de facto cela arrive souvent) de se trouver dans le cycle de maintenance d'un projet face à une classe dont on pensait l'interface à usage unique; or, les évolutions amène à multiplier les classes de ce type, et dans ce cas, on définira explicitement une interface pour ces classes.

Or, faire une extraction d'interface sur du code existant va impacter nettement plus l'ensemble des consommateurs de la classe si les variables membres publiques sont utilisées. (du fait qu'une Interface ne supporte pas les variables membres à l'exception des events).