Accesseurs C#, utilité ?

Salut la foule,

Après plusieurs années de développement Java, je suis passé voilà un an et demi au C#. Passage des plus aisé, à l'exception d'un point qui me pose un "problème", les accesseurs C#.

Depuis la nuit des temps, tous mes profs ont hurlé à qui voulait l'entendre que la bonne méthode pour modifier une valeur dans une classe consistait à utiliser les fameux get et set, et surtout pas l'accès à la variable public. Bref, c'est entré et c'est jamais ressorti...

Du coup, je ne comprends pas bien l'intérêt des accesseurs C#

Code:

---

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

public class MyClass { private string hello = "Hello World";   public MyClass(){ }   public string Hello { set { hello = value; } get { return hello; } }   static void Main(string[] args){ MyClass mc = new MyClass(); Console.Writeline(mc.Hello); } }

---

Vous l'aurez compris, la ligne Console.Writeline(mc.Hello); va à l'encontre de tout ce que l'on m'a appris, dans la mesure où on a vraiment l'impression d'accéder à une variable public... (contrairement à un getHello() et setHello() où l'encapsulation est bien plus claire)

Quelle est l'intérêt de cette methode ? Est-ce que l'on ne risque pas de confondre un accès à une variable public et un accesseur ? S'agit-il simplement d'un fonctionnement comme un autre et, ma foi, faut bien s'y habituer ?

En vous remerciant.

L'intérêt est d'alléger la syntaxe.
Mais si tu y tiens, tu peux créer des méthodes

Code:

---

1 2 3 4

public string getHello() { return hello; }

---

et

Code:

---

1 2 3 4

public void setHello(string nvHello) { hello = nvHello; }

---

Le "get" de la propriété Hello correspond exactement à une méthode getHello() et le "set" correspond exactement à une méthode setHello(value).

Le but est justement de "donner l'impression" d'accéder à un champ public - plus joli, plus intuitif que les fonctions getTruc et setTruc - tout en conservant la même qualité de contrôle sur l'accès aux données (tu n'es pas obligé de définir un get ou un set... et tu mets ce que tu veux dedans, même s'il est recommandé de ne pas y mettre de traitement lourd...)

Voir ce topic où j'avais répondu un peu plus longuement.

Les accesseurs sont en C# des méthodes qui ne disent pas leur nom.
Quand tu écris

Code:

---

1 2 3 4 5 6

public string Hello { set { hello = value; } get { return hello; } }

---

le compilateur va te générer (en gros) :

Code:

---

1 2 3 4 5 6 7 8 9

public void setHello(String value); { this.hello = value; } public string getHello(); { return this.hello; }

---

Après, effectivement, tu verras un mc.Hello dans ton code, mais je trouve assez pratique d'utiliser un nom unique pour l'obtention et l'affectation (notamment dans le cadre de la réflexion), mais c'est certainement une question d'habitude... Normalement, tu ne peux pas confondre avec un champ, qui doit commencer par une lettre minuscule. Libre à toi d'écrire directement les GetHello et SetHello si tu préfères.

[Edit]Désolé, j'ai répondu en même temps qu'Astartee[/Edit]

Non, ce n'est pas une variable, c'est une propriété...

Je vois pas ou est le problème ;)

Ne pas placer les membres en public permet d'empecher selon la convenance le get ou set.

Avec l'accesseur, tu peux retirer ton set, et sécuriser le membre souhaité, mais toujours le laisser accessible en get...

Il s'agit d'un simple confort de programmation : en msil la propriété est transformée en

Code:

---

1 2 3 4

public string get_Hello();   public void set_Hello(string value);

---

[edit] grillé....
A non, j'ai apporté la précision du "_" : merci reflector ;) [/edit]

ouaaaah le tir groupé :D

Venant de Java il est vrai que cela peut "pertuber", mais il n'y a pas de risque de confondre un accès via une variable publique ou via une propriété (ce que tu appelles accesseur).

Les EDI sont assez bien fait pour distinguer une propriété d'un champ et cela peut aussi passer par de la rigueur point de vue syntaxe du codage (casse Pascal pour les propriétés et Caml pour les champs par exemple).

Personnellement je trouve les propriétés plus sympathiques et "intuitives" au final, plutôt que d'avoir des méthodes Get/Set comme en Java :)

Citation:

---

Envoyé par StormimOn

, plutôt que d'avoir des méthodes Get/Set comme en Java :)

---

Au moins on y accede avec son nom, car vive l'intellisence avec 1000 gettruc() et settruc()...

L'intérêt est de fournir un mécanisme simple à devélopper pour le créateur, et pratique à utiliser pour l'utilisateur de la classe.
ça permet d'encapsuler une valeur qui apparait comme simple de l'extérieur de la classe, tout en pouvant faire des traitement supplémentaires dans la classe en interne.
Dans ton exemple, tu ne fais rien de particulier dans les get et set. Mais quand on développe des composants graphiques par exemple, on a des choses de ce genre :

Code:

---

1 2 3 4 5 6

public Color BackColor { get { return _backColor; } set { _backColor = value; Invalidate(); // Pour redessiner avec la nouvelle couleur } }

---

EDIT : Diantre ! J'arrive après la bataille, mais la prochaine fois, estimés collègues, ayez pitié des gens comme moi qui tapent avec des mouffles :aie: :
postez moins vite :D

Merci pour ces réponses, c'est donc bien une histoire de syntaxe à assimiler, il n'y a pas d'autres raisons plus profondes :) Bon ben je vais m'y mettre franchement, en espérant que, si je repasse à Java, je puisse retrouver mes reflexes get et set ;)