get et set en c#

Voici un code que j'ai teste:

1)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

private int login { public get { return login; } public set { login = value; } }

---

Je pensais pouvoir accéder et setter la valeur login grace au get et au set en public, mais je me rends compte que non, et qu'il faut ecrire le code suivant:

2)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

private int _login;   public int login { get { return _login; } set { _login = value; } }

---

3) ou a partir de c# 3 semble-t-il:

Code:

---

1 2	public int login {get; set;}

---

Voici ma question:

Puisque le code 1) qui compile ne permet pas d'acceder au setteur ni au getteur qui sont pourtant public, que le code 2) déclare 2 fois plus de variables que nécessaire, et que le code 3 ne déclare rien en private (pas terrible pour le respect du principe d'encapsualtion), je commence a me demander s'il n'est pas plus simple de tout simplement faire comme cela:

Code:

---

1 2	public int login;

---

Comment utilisez vous les get et set en c# et comment le justifiez vous?

Citation:

---

Envoyé par julien_iz

Puisque le code 1) qui compile ne permet pas d'acceder au setteur ni au getteur qui sont pourtant public

---

Normal puisque la propriété est marquée comme privée.

Citation:

---

Envoyé par julien_iz

que le code 2) déclare 2 fois plus de variables que nécessaire

---

Le code 2 ne déclare qu'une seule variable (_login). La propriété n'est pas une déclaration de variable mais juste un moyen d'y accéder.

Citation:

---

Envoyé par julien_iz

et que le code 3 ne déclare rien en private (pas terrible pour le respect du principe d'encapsulation)

---

Si mais c'est le compilateur qui s'en charge. L'encapsulation est toujours préservée via la propriété.

Bref, je pense que tu devrais revoir un peu la notion de propriété car tu sembles mélanger pas mal de choses. Une propriété c'est l'équivalent des méthodes GetMachin et SetMachin comme on fait en Java, sauf que les propriétés permettent d'avoir une écriture plus naturelle. Une fois compilé cela se traduit par des méthodes bien évidemment.

Ok, je pensais que les propriétés définissaient a la fois un attribut + getteur + setteur.
Y'a-t-il vraiment des cas ou une propriété n'est pas associée a un attribut qui lui est unique? :? (si la propriété ne déclare pas d'attribut dans le même temps, c'est qu'il y a certainement une raison...mais laquelle?)

Cependant, l'écriture suivante semble bien créer bien un attribut:

Code:

---

public int login { get; set; }

---

Ça crée un attribut seulement si on ne met pas de code dans le getteur ni dans le setteur? 8O

Citation:

---

Normal puisque la propriété est marquée comme privée.

---

Je me rends compte que les modificateurs de portée devant get et set sont obligatoirement plus restrictifs que la portée de la propriété. ;)

Citation:

---

Envoyé par julien_iz

Ok, je pensais que les propriétés définissaient a la fois un attribut + getteur + setteur.

---

Et non.

Citation:

---

Envoyé par julien_iz

Cependant, l'écriture suivante semble bien créer bien un attribut

Code:

---

public int login { get; set; }

---

Ça crée un attribut seulement si on ne met pas de code dans le getteur ni dans le setteur ?

---

Oui, c'est une nouveauté du compilateur C# 3.0. Cela peut laisser penser que les propriétés définissent un attribut mais ce n'est pas vrai, car au final le compilateur générera un attribut.

Merci pour les réponses :ccool:

Je trouve que c'est un peu laid tout ça.... :?
(ça aurait été plus simple que les propriétés "pondent" un attribut a chaque fois, pas seulement lorsqu'il n'y a pas de code dans le set ni dans le get)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public class Inutile {   private Hashtable myTable;   public int Count { get { return myTable == null ? 0 : myTable.Count; } }   }

---

Quel aurait été l'intérêt pour ce genre de code de créer "automatiquement" un attribut ?

Citation:

---

(ça aurait été plus simple que les propriétés "pondent" un attribut a chaque fois, pas seulement lorsqu'il n'y a pas de code dans le set ni dans le get)

---

Dans ce cas comment déterminer le nom du champ créé ?

Donc soit l'utilisateur gère tout : champ + propriété.
Soit il ne gère rien : champ + propriété auto-générés.

Citation:

---

Envoyé par Kaidan

[CODE]

Quel aurait été l'intérêt pour ce genre de code de créer "automatiquement" un attribut ?

---

J'aurais créé une méthode personnellement, mais en effet, voila un cas ou l'attribut est inutile :mouarf:

Citation:

---

Dans ce cas comment déterminer le nom du champ créé ?

---

public int login { get {return 0;}; set; }
public int login { get; set; }

Le compilo pourrait pas se débrouiller dans les 2 cas? Y'a juste a mettre un décorateur sur le nom de la propriete pour donner les nom de l'attibut et basta :P

Code:

---

public int login { get {return 0;}; set; }

---

Aucun intérêt : tu définis un setter sur un champ auto-généré, tu n'en connais donc pas le nom donc tu ne peux plus récupérer les valeurs.
Ca reviendrait à :

Code:

---

1 2 3 4 5 6 7 8 9 10

public int login { get { return 0; } set { } }

---

Donc oui le compilo pourrait se débrouiller en générant le code au dessus, mais le problème est qu'il laisserait passer silencieusement une erreur de conception.

Si setter n'a pas de sens alors il faut imposer le read-only :

Code:

---

1 2 3 4 5 6 7

public int login { get { return 0; } }

---

Plus généralement les outils de développement, ici le langage, doivent reposer le moins possible sur des règles implicites parfois subtiles.
Le code doit être le plus clair possible pour en faciliter la maintenance par des personnes pas forcément au fait de toutes les subtilités.
Le gain en concision est négligeable par rapport à la perte de sémantique.

On peut trouver ça trop implicite en effet.

Merci a tous pour vos réponses, je mets en résolu