Discussion :

[julien_iz]

Voici un code que j'ai teste:

1)

Code :

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

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 :

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

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 :

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

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 :

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

1
2
 
public int login;

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

[StormimOn]

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.

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.

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.

[julien_iz]

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 :

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

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?

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

[StormimOn]

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

Et non.

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

Code :

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

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.

[julien_iz]

Merci pour les réponses

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)

[Kaidan]

Code :

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

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 ?

[Pragmateek]

(ç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.

[julien_iz]

[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

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

[Pragmateek]

Code :

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

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 :

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

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 :

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

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.

[julien_iz]

On peut trouver ça trop implicite en effet.

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