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]

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.

[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; } ?

[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.