Discussion :

[NiamorH]

Bonsoir,

je me penche vers le C# depuis peu et j'ai vu qu'il était possible d'écrire des propriétés automatiques :

Code :

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

public string Prenom {get; set;}

Seulement lors de la compilation avec visual 2005 j'ai l'erreur :

must declare a body because it is not marked abstract or extern

Pour get et set qu'il semble prendre pour des déclarations de fonctions.

Alors ma question : les propriétés automatiques sont-elles dispo à partir de 2008 uniquement ?

Merci

[binoo]

Salut,

Elles sont disponibles depuis le frameWork 3.0, il me semble et je crois que VS 2005 a le framework 2.0. A confirmer

[NiamorH]

C'est effectivement l'hypothèse que j'émets aussi, mais je ne suis pas encore tombé sur la confirmation. Si toi ou quelqu'un d'autre trouve une source, ce serait sympa de la faire tourner.

[StormimOn]

C'est effectivement l'hypothèse que j'émets aussi, mais je ne suis pas encore tombé sur la confirmation. Si toi ou quelqu'un d'autre trouve une source, ce serait sympa de la faire tourner.

http://michaelsync.net/2008/02/29/c-...tic-properties

Personnellement je n'aime pas trop ce système, trop automatisé peut être pour moi
Une habitude à prendre si l'on développe sur du 3.x ? Des retours sur expériences ?

[NiamorH]

Merci pour la source.

Je trouve le système pas mal lorsqu'on veut réduire la portée du set et que la propriété ne lève pas d'événements :

Code :

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

public int AnneeNaissance { get; private set; }

Typiquement, l'année de naissance sera renseignée une fois pour toute dans le constructeur et on pourra aller la lire comme bon nous semble sans la modifier. L'écriture semble parfaitement adaptée pour cet emploi.

Par contre, je trouve idiot d'écrire :

Code :

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

public int Age { get; set; }

Si je ne veux faire aucun contrôle ni aucune notification, je préfére encore écrire :

Code :

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

public int Age;

[SaumonAgile]

Effectivement elles sont dispo avec le compilateur .NET 3.5.
Elles permettent de supprimer une bonne partie du code qui ne sert à rien dans beaucoup d'objets.

[SaumonAgile]

Par contre, je trouve idiot d'écrire :

Code :

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

public int Age { get; set; }

Si je ne veux faire aucun contrôle ni aucune notification, je préfére encore écrire :

Code :

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

public int Age;

C'est justement là que les débutants se plantent à chaque fois.
Les propriétés ne servent pas accéder à un attribut (au sens développement), elles servent à exposer un attribut (au sens conceptuel) d'un objet dans le cadre de l'encapsulation.
Prends l'exemple d'un objet qui expose un liste de sous-objets, toi tu ferais ça :

Code :

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

public List<Toto> Totos;

Le jour où tu décides que ta liste de Toto n'est plus gérée en interne par une List<T> mais par un HashSet par exemple, tu seras obligé de modifier tout le code dépendant.
Alors que tu avais défini dès le départ une propriété tu n'aurais eu que la propriété à modifier.

Et je ne parle même pas du fait que les attributs en public sont généralement reconnus comme une mauvaise pratique (toujours par rapport à la notion d'encapsulation).

[NiamorH]

Prends l'exemple d'un objet qui expose un liste de sous-objets, toi tu ferais ça :

Code :

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

public List<Toto> Totos;

Heu, non... Qu'est ce qui peut te faire penser, dans ce que j'ai dit plus haut, que je ferais comme ça ?

Tout ce que j'ai dit c'est je n'écrirais jamais :

Code :

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

public int Age { get; set; }

Puisque c'est (vraissemblablement) identique, en utilisation et en logique (ne nous voilons pas la face derrière des pseudos prétextes d'encapsulation ici), à :

Code :

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

public int Age;

J'espère que tu conviendras que les deux écritures ne respectent, ni l'une, ni l'autre, l'encapsulation et c'était là le seul point de ma remarque.

[NiamorH]

Je trouve le système pas mal lorsqu'on veut réduire la portée du set et que la propriété ne lève pas d'événements :

Code :

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

public int AnneeNaissance { get; private set; }

Typiquement, l'année de naissance sera renseignée une fois pour toute dans le constructeur et on pourra aller la lire comme bon nous semble sans la modifier. L'écriture semble parfaitement adaptée pour cet emploi.

Je reviens sur ce que j'ai dit ici : je viens de découvrir le mot-clef readonly qui permet lui aussi de modifier la valeur dans le constructeur : http://msdn.microsoft.com/en-us/libr...b7(VS.80).aspx

Code :

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

public readonly int AnneeNaissance;

Donc je ne vois plus aucune raison d'utiliser les propriétés automatiques.

[Guulh]

Code :

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

public int Age { get; set; }

Puisque c'est (vraissemblablement) identique, en utilisation et en logique (ne nous voilons pas la face derrière des pseudos prétextes d'encapsulation ici), à :

Code :

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

public int Age;

J'espère que tu conviendras que les deux écritures ne respectent, ni l'une, ni l'autre, l'encapsulation et c'était là le seul point de ma remarque.

Pourquoi affirmes-tu que les proprietes autom. ne respectent pas l'encapsulation ?
Effectivement, a l'utilisation, on ecrira classe.Age dans un cas comme dans l'autre. Mais c'est un "breaking change" : quand tu codes une bibliotheque, tu peux pas te permettre de changer ce qui etait un champ public en propriete. Entre autres a cause de la reflexion : y'a peut etre du code qui va recuperer la propriete Text" d'un Control par reflexion en faisant machin.GetProerty("Text", ...), code aui marchera plus si Text n'est plus une propriete mais un simple champ public. Et inversement.

On remarquera que les classes du framework n'ont (a ma connaissance) jamais de champ public.

C'est la que les proprietes automatiques sont tres bien : elles permettent de tout encapsuler sans polluer le code avec des declarations inutiles. Ca permet d'uniformiser le "contrat" que presente une classe, tout en lui laissant de la flexibilite dans son evolution future.

Ah, et cette syntaxe courte est bien dispo en Visual 2005 : en C++/CLI

[popachubby]

public int Toto;

et

public int Toto{get; set;}

ne sont équivalents que pour pour la personne qui s'occupe du code client. Derrière ce n'est pas la même chose.
Par exemple, tu ne peux faire de vrai databinding qu'avec des propriétés, pas des champs. D'où l'interêt des propriétés automatiques.
Sans compter la facilitation au niveau maintenance : si tu dois après coup rajouter un traitement sur la valorisation du champ par ex., tu devras rajouter une méthode du genre "SetToto(int toto)" et modifier le code client. Avec les proprétés, non.

[StormimOn]

On remarquera que les classes du framework n'ont (a ma connaissance) jamais de champ public.

Il y a des champs publics dans le framework, mais ils sont utilisés à bon escient, c'est à dire pour des champs constants (const ou readonly).

DateTime.MinValue ou DateTime.MaxValue par exemple

[Guulh]

Il y a des champs publics dans le framework, mais ils sont utilisés à bon escient, c'est à dire pour des champs constants (const ou readonly).

DateTime.MinValue ou DateTime.MaxValue par exemple

Oui, je voulais dire de champ public modifiable.

[NiamorH]

Ok, ce sont de bons arguments.

Effectivement, a l'utilisation, on ecrira classe.Age dans un cas comme dans l'autre. Mais c'est un "breaking change" : quand tu codes une bibliotheque, tu peux pas te permettre de changer ce qui etait un champ public en propriete. Entre autres a cause de la reflexion : y'a peut etre du code qui va recuperer la propriete Text" d'un Control par reflexion en faisant machin.GetProerty("Text", ...), code aui marchera plus si Text n'est plus une propriete mais un simple champ public. Et inversement.

C'est vrai. N'ayant pas l'habitude d'utiliser la réflexion, je n'avait pas pensé à ce que le code client puisse utiliser le fait que Age SOIT une propriété.
+1 pour les propriétés (automatiques ou non)

C'est la que les proprietes automatiques sont tres bien : elles permettent de tout encapsuler sans polluer le code avec des declarations inutiles.

Ca c'est un avantage des propriétés automatiques face au propriétés simples, pas face au attributs membres publiques.

Ca permet d'uniformiser le "contrat" que presente une classe, tout en lui laissant de la flexibilite dans son evolution future.

La je n'ai pas très bien saisi.

Par exemple, tu ne peux faire de vrai databinding qu'avec des propriétés, pas des champs. D'où l'interêt des propriétés automatiques.

Des propriétés tout court en fait.
Ok + 2 pour les propriétés : le databinding. Je n'en ai encore jamais fait, donc je n'y ai pas pensé.

ne sont équivalents que pour pour la personne qui s'occupe du code client.

Et bien, même pas, si celle-ci ne peut pas faire de databinding ni de réflexion...

Sans compter la facilitation au niveau maintenance : si tu dois après coup rajouter un traitement sur la valorisation du champ par ex., tu devras rajouter une méthode du genre "SetToto(int toto)" et modifier le code client. Avec les proprétés, non.

Alors pas d'accord. Si j'ai :

Code :

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

1
2
3
4
class Truc
{
  public int Age;
}

Et que je veux interdire dans le futur de mettre un age négatif :

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
class Truc
{
  private int m_age;
  public int Age
  {
    get { return m_age; }
    set
    {
      if ( value < 0 )
        return;
 
      m_age = value;
    }
  }
}

Code modifié chez le client ? nada

Pourquoi affirmes-tu que les proprietes autom. ne respectent pas l'encapsulation ?

Ce n'est que mon point de vue. Si, d'un côté, je déclare ma donnée privée, et que de l'autre, si l'on me la demande, je la rends telle quelle et si l'on veux la modifier, je la modifie sans contrôle ni levée d'événement, je considère que mon encapsulation est illusoire, et que la donnée aurait très bien pu être directement accessible.

Un parallèle : un agent de sécurité à l'entrée d'une grosse boite.
Il contrôle qui rentre et qui sort. Il arrive qu'il contrôle les sacs également et si il voit quelque chose de suspect il prévient la sécurité.
Si tu lui demande de laisser rentrer et sortir tout le monde et ne plus rien vérifier, il ne sert plus à rien, autant le virer. Bon ok dans mon exemple, rien que le voir posté à l'entrée te fait réfléchir avant de rentrer pour faire une connerie, mais bon... tu vois l'idée ?

Bon, maintenant que je vois que les propriétés peuvent apporter en soi d'autres avantages, je modère mes propos et comprends l'autre intérêt (parce que ça n'a plus rien à voir avec l'encapsulation mais plutôt avec des services offerts par les propriétés) des propriétés.

En espérant m'être exprimé clairement !

[Guulh]

En espérant m'être exprimé clairement !

Tres clair, oui je vais essayer de l'etre autant.

Le point sur lequel j'insiste, c'est la compatibilite. Imagine une assembly A.dll avec une classe C, avec :

Code :

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

1
2
3
4
class C
{
public int I;
}

Cette assembly est une bibliotheque, que tu fournis a un client / une autre equipe de ta boite.

Cette autre equipe va effectivement utiliser cette classe avec monC.I = un entier.
"Ah, c'est un champ public ! donc apres avoir fait monC = 500, l'assertion monC == 500 est forecement vraie !" se dira-t-il, et il aura raison (j'oublie pour la demo les problemes de multi-threading).

Puis tu livres la version 1.1 de ton assembly, où tu veux faire un controle sur la valeur de I. Par exemple :

Code :

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

1
2
3
4
5
class C
{
private int i;
public int I {get {return i; } set { i = Math.Min(100, value; } }
}

Effectivement, le code de l'equipe a laquelle tu as file ton assembly compilera toujours. Mais tu l'obliges a recompiler ! Ta dll 1.1 ne fonctionnera pas avec l'exe 1.0 parce que celui ci partait du principe que I etait un champ. Mais c'est une propriete, pas un champ.
En plus, la supposistion qu'il avait faite deviendra fausse. Alors que si on avait mis une propriete depuis le debut, il n'aurait pas pu supposer que recuperer la valeur de I renverra forcement la valeur qu'on vient de lui donner.

Les langages de haut niveau comme c# masquent toute une plomberie ; mais le code MSIL genere derriere est completement different.

Donc : il vaut mieux donner acces a des variables via des proprietes : ca uniformise ce que voit l'utilsateur de la classe, tout en permettant des evolutions de code qui ne necessitent pas de recompil. Et puis avec l'inlining et le compilo C# malin, ca ne change rien aux perfs.

Voila, et desole pour le manque d'accents, je suis sur un qwerty

[NiamorH]

Ok, ben c'est encore un bon argument.

Et pour les accents, je trouve ça inadmissible!

[Guulh]

J'ai quand meme mis un accent ds mon post precedent, sauras-tu le retrouver

J'ajoute juste que C# a beaucoup de sucre syntaxique, qui simplifie considerablement le code mais qu'il faut bien comprendre. A savoir que :

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
class C1
{
private int i;
public int getI() { return i; }
public int setI(int value) { i = value; }
}
class C2
{
private int i;
public int I { get {return i; } set { i = value; } }
}
class C3
{
public int I { get ; set ; }
}

sont conceptuellement equivalents. sauf que C2 est plus facile a utiliser que C1 (vive a.Truc.Bidule = b.Machin[truc].Chouette plutot qu'un ecnhainement de la mort d'appels a des getTruc et setMachin) et que C3 est plus lisible que C2. Mais le code MSIL genere est le meme. Ce n'est qu'une question de syntaxe.

[NiamorH]

On est d'accord

J'ai quand meme mis un accent ds mon post precedent, sauras-tu le retrouver

Ici :

ù

[Emmanuel Deloget]

C'est justement là que les débutants se plantent à chaque fois.
Les propriétés ne servent pas accéder à un attribut (au sens développement), elles servent à exposer un attribut (au sens conceptuel) d'un objet dans le cadre de l'encapsulation.
Prends l'exemple d'un objet qui expose un liste de sous-objets, toi tu ferais ça :

Code :

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

public List<Toto> Totos;

Le jour où tu décides que ta liste de Toto n'est plus gérée en interne par une List<T> mais par un HashSet par exemple, tu seras obligé de modifier tout le code dépendant.
Alors que tu avais défini dès le départ une propriété tu n'aurais eu que la propriété à modifier.

Et je ne parle même pas du fait que les attributs en public sont généralement reconnus comme une mauvaise pratique (toujours par rapport à la notion d'encapsulation).

Et c'est quoi la différence avec public List<Toto> Toto { get; set; } ?