But des accesseurs en C#

Salut à tous,

Comme à chaque fois que je lance mon Visual Studio j'ai le droit à la page de démarrage qui me donne les nouvelles fraiches dans le monde de .NET

Il y a quelque semaine je suis tombé sur un article que je n'arrive pas à oublier tellement il me hante. :aie:
Voici le lien pour l'article en question :
Le sucre sytaxique du C# 3.0

Je vous laisse le consulter, c'est juste la première partie qui m'intéresse celle parlant des accesseurs.

Je me suis toujours demandé à quoi pouvait bien servir les accesseurs en C# puisque ce sont des propriétés et pas vraiment des accesseurs :aie:
Le rôle de celui-ci est d'encapsuler l'information, or la propriété en C# ne le fait pas vraiment, en plus d'introduire une nouvel convention de nommage pour un attribut ... :aie:

Mais le comble c'est qu'on peut avoir des accesseurs asymétrique comme montré dans la doc.

Pour finir on sait plus se qu'on fait ... :aie:

Me trompe-je ?

Je mettrais des exemples plus parlant un peu plus tard, pour que ce soit plus visuel. Mais là il faut que j'aille au resto :aie:

Merci pour vos réactions

Citation:

---

Envoyé par LhIaScZkTer

Je me suis toujours demandé à quoi pouvait bien servir les accesseurs en C# puisque ce sont des propriétés et pas vraiment des accesseurs :aie:
Le rôle de celui-ci est d'encapsuler l'information, or la propriété en C# ne le fait pas vraiment

---

Je ne suis pas d'accord. La propriété permet d'accéder à une variable privée mais pas de manière directe puisque l'on passe par la propriété.

Il faut bien voir que les propriétés ne sont qu'une façon d'écrire l'accesseur et le mutateur en regroupant ces 2 notions sous 1 seule. Cela revient donc à la même chose que des méthodes GetMachin() et SetMachin(...), sauf que l'écriture et la lecture sont plus intuitives, avis personnel bien évidemment. Aucune rupture de l'encapsulation donc.

Citation:

---

Envoyé par LhIaScZkTer

Mais le comble c'est qu'on peut avoir des accesseurs asymétrique

---

Ce n'est pas une question de comble, c'est logique et très pratique. Avec des méthodes Get et Set tu aurais le même phénomène. Un traitement interne peut avoir besoin d'initialiser des membres (set en internal ou protected), mais de l'extérieur on ne peut qu'y accéder (get public).

Je ne comprends pas trop ce qui te turlupine... :P

Le rôle de la propriété ou de l'accesseur, si tu veux les distinguer est d'encapsuler l'information. Oui, c'est à dire ne pas exposer directement les membres. Pourquoi? Si le type, le nom, le traitement, tout ce que tu veux change dans ta classe, tant que tu conserves la propriété tel quelle, cela n'aura aucune influence pour ce qui utilise ta classe.

Tu peux par exemple avoir une collection en membre qui soit une hastable, et une propriété IEnumerable qui ne renvoie que les valeurs. Si tu change ta collection en n'importe quoi d'autre, tant que tu renvois un IEnumerable dans la propriété, c'est ok.

Ca permet également d'offrir une information qui n'aurait pas forcément de sens à l'intérieur même de la classe. exemple :

Code:

---

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

public class Joueur { private int _Morts = 0; private int _Tues = 0;   int Score { get { return _Tues - _Morts; } } }

---

Le Score est une information combinée de 2 autres. Il est en get, aucune autre classe ne peux l'affecter.
Si le set était présent et asymétrique en protected , seul les classes héritées pourrait le modifier.


Le but des propriétés est de simplifier la lecture et le dev, c'est quand même mieux que d'avoir 100 méthodes get...() et set...() pour changer des infos, non? :aie:


Et si je te dis qu'a la compilation toutes tes propriétés sont transformées en méthodes?
Par exemple précédemment :

Code:

---

1 2 3 4

public int get_Score() { return ...; }

---

Salut StormimOn, Chubyone merci pour vos réponses :king:

Citation:

---

Je ne suis pas d'accord. La propriété permet d'accéder à une variable privée mais pas de manière directe puisque l'on passe par la propriété.

---

+1 StormimOn évidemment que je suis d'accord avec toi. Même si à la déclaration c'est explicite, lors de l'utilisation cela devient, d'un point de vu visuel, implicite. Et là ou ça le devient encore plus implicite, toujours d'un point de vu visuel, c'est quand tu utilises des accesseurs asymétrique. Car il ne faut pas oublier que tu n'es pas toujours le développeur de la class que tu utilises, et donc en ayant :

Code:

---

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

public class Chiffre{   private int googolplex;   protected void setGoogolplexProtect(int googolplex){ this.googolplex= googolplex; } public int getGoogolplex(){ return this.googolplex; } }

---

Dans ce cas de figure, tout devient explicite visuellement, car tu sais qu'à l'assignation (ou mutation comme tu veux :aie: ) la donnée va dans un setter protected, vu que le nom de la méthode est explicite :aie:

Même si dans ce cas là il aurait peut-être été préférable(plus logique) de faire directement :

Code:

---

1 2 3 4 5 6 7 8 9

public class Chiffre{   protected int googolplex;   public int getGoogolplex(){ return this.googolplex; } }

---

Ce qu'il faut retenir la dedans, c'est que je ne parle que d'un point de vue visuel. A force de trop vouloir simplifier le code on déresponsabilise le développeur, non ?

Citation:

---

Le rôle de la propriété ou de l'accesseur, si tu veux les distinguer est d'encapsuler l'information. Oui, c'est à dire ne pas exposer directement les membres. Pourquoi? Si le type, le nom, le traitement, tout ce que tu veux change dans ta classe, tant que tu conserves la propriété tel quelle, cela n'aura aucune influence pour ce qui utilise ta classe.

---

:alerte: Là ou je diverge avec toi, c'est que dans ton cas de figure. Une manipulation hasardeuse de la class ne produirait pas une erreur de compilation au même endroit, et justement si, cela aura une incidence :aie:

Exemple ou l'incidence se voit tout de suite :

Code:

---

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

public class Chiffre{   private int googolplex; //Si tu changes le type et que tu le transforme en string de même pour le nom   public void setGoogolplex(int googleplex){ this.googolplex= googolplex; //Tu te retrouves avec une erreur de complication } public int getGoogolplex(){ return this.googolplex; //Ici aussi } }

---

Et exemple ou l'incidence est déplacée :

Code:

---

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

public class Chiffre{   public int Googolplex{//Si tu transforme en string pas de souci ici, et donc, c'est carrement ta structure de données qui est différente get; set; } }   class JegoogleplexMain { static void Main(){ int myGoogolplex = 0; Chiffre myChiffre = new Chiffre(); /*   ... tout les calculs(traitement) qu'on veut ...   */ myGoogolplex = myChiffre.Googolplex; // par contre c'est ici que tu auras un problème } }

---

Donc, si un autre développeur change la class Chiffre, alors que l'appli est déjà en production, et que celui-ci est autiste, et qu'il oublie de dire au développeur de la class main qu'il y a eu des Updates. Ils ne se rendront compte que lors du lancement de l'appli. Enfin c'est juste pour dire qu'on déplace le problème :aie:

+1000 Quand tu évoques la lecture du code, mais comme je l'ai dis plus haut, tu déresponsabilise le développeur, qui à force peut se mélanger les pinceaux(ou pas) :aie:

Au même temps pour les structures de données qui ont 100 get/set, c'est justement à ça qu'elles servent, car en définissant des accesseurs avec des termes plus précis on y voit plus claire en cas d'asymétrie, par exemple. Comment appel-t-on ça déjà ? Des Pojo, JavaBean ou C#Bean(si ça existe) :aie:

Et pour finir, j'espère Chubyone que tu n'es pas sérieux quand tu me dis parle de la transformation des propriétés. Car là, en plus d'être hanté je deviendrais insomniaque, et à cause de toi en plus :aie:

Ce que tu me dis, est-ce bien ce que je crois ? :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

//Pour C# la transformation suivante lors de la compilation en utilisant la syntaxe 3.0 ->public int Entier{ get; set; } ->//Qui va créer mon attribut private entier, implicitement lors de la compilation ->//Qui ensuite va transformer mon Entier en méthode get_Entier et set_Entier ->//Qui pour finir le transformera enfin en MSIL ou plutôt en CIL et qui nous sortira enfin un truc dans le genre 66850 load 6xf00d //C'est du factice évidemment :lol: 66950 mov 2x11ac

---

Je viens de comprendre pourquoi j'ai acheté un Quad core avec 4GO de ram. A force avec tout ce micmac les performances vont en pâtir, encore une fois me trompe-je ? :aie:

Merci pour vos réactions, j'ai pas voulu trop entré dans le détail :aie:

Citation:

---

Envoyé par LhIaScZkTer

... lors de l'utilisation cela devient, d'un point de vu visuel, implicite. Et là ou ça le devient encore plus implicite, toujours d'un point de vu visuel, c'est quand tu utilises des accesseurs asymétrique ...

---

Il s'agit d'un problème de documentation à ce stade je pense et la documentation XML du code n'est pas là que pour faire jolie. Charge à toi de documenter et commenter ton code, pour les utilisateurs et toi même bien évidemment, ça aide lorsqu'il faut reprendre un code 1 an après :D

Citation:

---

Envoyé par LhIaScZkTer

Même si dans ce cas là il aurait peut-être été préférable(plus logique) de faire directement :

Code:

---

1 2 3 4 5 6 7 8 9

public class Chiffre { protected int googolplex;   public int getGoogolplex() { return this.googolplex; } }

---

---

En faisant ça tu ne respectes plus l'encapsulation, si on va au bout de la chose. La variable étant protégée, elle est directement accessible des classes enfants. La classe qui déclare la variable n'a plus la main sur ce que l'on fait de la variable.

Il vaut mieux une propriété protégée avec une variable privée qu'une simple variable protégée, enfin c'est juste mon avis :aie:

Citation:

---

Envoyé par LhIaScZkTer

Ce qu'il faut retenir la dedans, c'est que je ne parle que d'un point de vue visuel. A force de trop vouloir simplifier le code on déresponsabilise le développeur, non ?

---

Les propriétés sont certes une simplicité d'écriture, mais il n'y a aucun inconvénient à les utiliser, même "visuellement". Très franchement, je ne vois pas en quoi les propriétés déresponsabilisent les développeurs :koi:

Par contre le principe des propriétés du .Net 3 où on déclare des get/set vides et le compilateur fait le reste ne me plait pas du tout. Ça doit dépendre suivant les IDE, mais sinon des snippets existent pour ça si on est vraiment super fainéant :D

Citation:

---

Envoyé par LhIaScZkTer

Et pour finir, j'espère Chubyone que tu n'es pas sérieux quand tu me dis parle de la transformation des propriétés. Car là, en plus d'être hanté je deviendrais insomniaque, et à cause de toi en plus

---

Les propriétés sont juste une simplification syntaxique, à la compilation des méthodes sont générées. Le MSIL fait apparaître des méthodes (une pour le get et une pour le set, s'il y a un set bien évidemment). Si tu cherches sous google tu trouveras des articles qui en parle je pense.