Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2015-05-12T11:42:17+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Question sur l'encapsulation des attributs, message #564762015-05-12T11:42:17+02:00lmghs/@lmghshttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56476<p>Je sais aussi penser en termes de données. Et dans ce cas là, il ne s'agit que de données et pas de trucs bâtards de type données derrière une fonction qui rajoute un intermédiaire pour faire plaisir à ceux qui n'ont pas compris ce qu'est l'encapsulation.</p>
<p><code>rect.x() += 2</code> me parait être ce qu'il y a probablement de pire en terme de choix. À moins d'un encodage vraiment particulier de l'abscisse, cette surcouche n'apporte rien.</p>
<p>PS: je dois faire parti des rares personnes qui préfèrent voir un code planter si l'interface d'accès à une donnée change parce que la représentation de la donnée a changé. Cela me permet de juger s'il y a besoin de revoir les accès ou pas. Maintenant, c'est une situation que je n'ai pratiquement jamais rencontré. Je suis de fait prêt à payer le prix d'un changement d'interface de temps à autres : le prix est largement amorti depuis le temps. Mais bon, comme tu l'as dit, je suis principalement dans un paradigme de services -> d'où que mes interfaces ne dépendent pas de données, et que donc je n'ai pas le problème du changement de représentation qui influe l'interface.</p>Question sur l'encapsulation des attributs, message #564252015-05-11T21:41:13+02:00jo_link_noir/@jo_link_noirhttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56425<p>@lmghs: tu penses en terme de service et non de données :).</p>
<p>C'est pénible d'avoir une structure de donnée qui, suite a l'ajout d'un intermédiaire, modifie une grande quantité de code. En plus, on utilise différemment les facilitateurs¹ et les variables (donc des syntaxes différentes). On finit par ne plus savoir qui est fonction et qui est variable.</p>
<p>Note que pour les objets de donnée, je n'imagine pas de setter mais un observer qui retourne une référence (ou un proxy): <code>rect.x() += 2;</code></p>
<p>¹ facilitateurs: fonction membre qui retourne un ensemble restreint des données (ex: fonction position() d'une classe rectangle {x,y,z,h}).</p>Question sur l'encapsulation des attributs, message #563952015-05-11T20:26:28+02:00felko/@felkohttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56395<p>Salut,</p>
<p>Merci à tous pour vos réponses, nous avons finalement opté pour une structure pour le point et pour le rectangle.</p>
<p>Je passe le sujet en résolu, merci encore.</p>Question sur l'encapsulation des attributs, message #563412015-05-11T15:44:38+02:00lmghs/@lmghshttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56341<p>Les setters sont des décapsuleurs.</p>
<p>La vraie question à te poser est : <em>"est-ce que la classe a (/pourra avoir) des invariants?"</em>. Si la réponse est non, alors setters et getters n'ont aucun sens. C'est particulièrement vrai avec tous les exemples de type point. Et que l'on passe par <code>p.x()</code>, ou <code>p.x</code>, Déméter ne s'en portera pas mieux, à contrario de passer par <code>make_point(x,y)</code>, <code>p1 + 42.12 * (p1 - p2)</code>, …</p>
<p>Bref, l'objectif de l'encapsulation n'est pas de cacher les données pour le plaisir de les cacher, c'est de garantir le respect des invariants.</p>
<p>Bref. J'ai plein de lecture sur le sujet, et j'ai la flemme de les trier alors que cela a déjà été fait <a href="http://zestedesavoir.com/forums/sujet/2473/dereferencement-dun-objet/?page=1#p44612">ici même</a>: </p>
<ul>
<li><a href="http://www.developpez.net/forums/d1294290/c-cpp/cpp/bonnes-pratiques-convention-commenter-code-cpp/#post7052654">http://www.developpez.net/forums/d1294290/c-cpp/cpp/bonnes-pratiques-convention-commenter-code-cpp/#post7052654</a></li>
<li><a href="http://www.artima.com/intv/goldilocks3.html">http://www.artima.com/intv/goldilocks3.html</a></li>
<li><a href="http://openclassrooms.com/forum/sujet/probleme-d-amitie-63712#message-6675973">http://openclassrooms.com/forum/sujet/probleme-d-amitie-63712#message-6675973</a></li>
<li><a href="http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and">http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and</a></li>
<li><a href="http://stackoverflow.com/questions/565095/are-getters-and-setters-poor-design-contradictory-advice-seen">http://stackoverflow.com/questions/565095/are-getters-and-setters-poor-design-contradictory-advice-seen</a></li>
<li><a href="http://forum.ubuntu-fr.org/viewtopic.php?pid=14721711#p14721711">http://forum.ubuntu-fr.org/viewtopic.php?pid=14721711#p14721711</a></li>
<li><a href="http://openclassrooms.com/forum/sujet/java-accesseurs-et-mutateurs?page=1#message-85371575">http://openclassrooms.com/forum/sujet/java-accesseurs-et-mutateurs?page=1#message-85371575</a></li>
<li><a href="http://www.javaworld.com/article/2072302/core-java/more-on-getters-and-setters.html">http://www.javaworld.com/article/2072302/core-java/more-on-getters-and-setters.html</a></li>
<li><a href="http://stackoverflow.com/questions/565095/are-getters-and-setters-poor-design-contradictory-advice-seen">http://stackoverflow.com/questions/565095/are-getters-and-setters-poor-design-contradictory-advice-seen</a></li>
<li><a href="http://www.idinews.com/quasiClass.pdf">http://www.idinews.com/quasiClass.pdf</a></li>
<li><a href="http://typicalprogrammer.com/doing-it-wrong-getters-and-setters/">http://typicalprogrammer.com/doing-it-wrong-getters-and-setters/</a></li>
<li><a href="http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html">http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html</a></li>
</ul>Question sur l'encapsulation des attributs, message #563152015-05-11T12:40:16+02:00Taurre/@Taurrehttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56315<figure><blockquote>
<p>Je crois (les spécialistes me corrigeront au besoin) que en C++, une classe et une struct sont exactement la même chose, sauf que les membre d'une classe sont <code>private</code> par défaut, et les membres d'une struct sont en <code>public</code> par défaut.</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56271">Luthaf</a></p></figcaption></figure><p><em>Ah</em> ! À la lecture de la norme C++-11 tu sembles avoir raison. Il en va appremment de même pour les unions :</p>
<figure><blockquote>
<p>A union is a class defined with the class-key union; it holds only one data member at a time […].</p>
</blockquote>
<figcaption><p>C++-11, doc. N3242, § 9, al. 5</p></figcaption></figure><figure><blockquote>
<p>A standard-layout class is a class that:</p>
<ul>
<li>has no non-static data members of type non-standard-layout class (or array of such types) or reference,</li>
<li>has no virtual functions (10.3) and no virtual base classes (10.1),</li>
<li>has the same access control (Clause 11) for all non-static data members,</li>
<li>has no non-standard-layout base classes,</li>
<li>either has no non-static data members in the most derived class and at most one base class with
non-static data members, or has no base classes with non-static data members, and</li>
<li>has no base classes of the same type as the first non-static data member.</li>
</ul>
<p>A standard-layout struct is a standard-layout class defined with the class-key struct or the class-key class.
</p>
</blockquote>
<figcaption><p>C++-11, doc. N3242, § 9, al. 7 et 8</p></figcaption></figure><p>Merci pour cette précision.</p>Question sur l'encapsulation des attributs, message #562852015-05-11T01:01:16+02:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56285<p>En réalité, les getters et setters vont servir surtout dans ce type de classe: ils sont indépendants de l'implémentation.</p>
<p>Si pour accéder à la position x du rectangle je dois faire rect.pos.x, Demeter ne va pas être très content. Par contre avec rect.x(), je me fiche totalement des intermédiaires.
En plus, manipuler x,y et w,h n'est pas symétrique.
Autre exemple, si w et h sont regrouper dans une classe Bounds, il va falloir remplacer tous les rect.w en rect.bounds.w, pas s'il y a des getters/setters.</p>
<p>Ma solution préférée reste cependant l'usage de fonctions libres, Rect ne devient qu'un contexte de données qui n'est jamais directement manipulé. C'est aussi plus facile de faire de la programmation générique avec des fonctions libres (quand plusieurs classes Rectangle de différentes bibliothèques cohabitent dans l'application).</p>
<p>(Cela me fait vaguement penser à cette <a href="http://www.developpez.net/forums/d1510280/c-cpp/cpp/langage/utilisation-types-utilitaires-lib-vecteurs-point-etc/">discussion</a>.)</p>Question sur l'encapsulation des attributs, message #562732015-05-10T22:10:18+02:00unidan/@unidanhttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56273<p>En l'occurrence ici, ça touche plus du domaine de la structure de données (on définit ce qu'est un rectangle, et même carrément on ne définit pas d'opération élémentaires dessus) que de la classe : quel est le service rendu par la classe Rect ? Manipuler les Rect ? Dans ce cas c'est bien une structure de données.</p>
<p>Les getter/setter, comme dit par les voisins du dessus, sont réservés à des cas assez restreint, déjà où il n'y a matériellement pas le choix (temps, code déjà fait) et seulement si la classe est sujet à des vérifications/observations.</p>
<p>Ici, la vérification pourrait être que w et h sont positifs, mais elle peut être évitée en mettant des unsigned. Niveau vérifications/observations supplémentaires, la classe en elle même n'en a pas besoin, donc c'est une autre classe qui aurait besoin de ces vérifications => pas besoin. </p>Question sur l'encapsulation des attributs, message #562712015-05-10T21:57:57+02:00Luthaf/@Luthafhttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56271<figure><blockquote>
<figure><blockquote>
<p>PS: Pour une classe aussi simple c'est pas plus facile de faire une <code>struct</code> ?</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56259">AlphaZeta</a></p></figcaption></figure><p>J'aurais tendance à dire qu'une classe a effectivement peu d'intérêt dans cette situation. Toutefois, j'utilise pour ma part le C, il y a donc peut-être des motifs pour utiliser une classe qui m'échappent.
</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56270">Taurre</a></p></figcaption></figure><p>Je crois (les spécialistes me corrigeront au besoin) que en C++, une classe et une struct sont exactement la même chose, sauf que les membre d'une classe sont <code>private</code> par défaut, et les membres d'une struct sont en <code>public</code> par défaut.</p>Question sur l'encapsulation des attributs, message #562702015-05-10T21:52:23+02:00Taurre/@Taurrehttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56270<p>Salut,</p>
<figure><blockquote>
<p>Mais Qames (celui avec qui je code le projet) me dit de mettre les attributs en <code>private</code> et de faire des <em>getter</em> et <em>setter</em>, sous prétexte que c'est plus sécurisé. Mais si le code des accesseurs sont "classiques" c'est à dire <code>T getAttr() { return attr; }</code> pour le <em>getter</em> et <code>void setAttr(T val) { this->attr = val; }</code> pour le <em>setter</em>, alors à quoi bon ? Ca revient au même, non ?</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56259">AlphaZeta</a></p></figcaption></figure><p>En l'état actuel, oui, le résultat est identique. Cependant, si vous décidez de modifier le code par après et, par exemple, d'effectuer des vérifications et/ou modifications sur les valeurs fournies, alors l'utilisation des méthodes vous évitera de devoir modifier votre code. Maintenant, nous sommes d'accords : c'est assez peu probable dans ce cas ci.</p>
<figure><blockquote>
<p>PS: Pour une classe aussi simple c'est pas plus facile de faire une <code>struct</code> ?</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56259">AlphaZeta</a></p></figcaption></figure><p>J'aurais tendance à dire qu'une classe a effectivement peu d'intérêt dans cette situation. Toutefois, j'utilise pour ma part le C, il y a donc peut-être des motifs pour utiliser une classe qui m'échappent.</p>Question sur l'encapsulation des attributs, message #562622015-05-10T20:45:17+02:00Olybri/@Olybrihttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56262<p>Salut,</p>
<p>Ici, il n'y a aucun n'intérêt à utiliser un getter/setter, car les attributs peuvent accepter n'importe quelle valeur à tout moment. Je ne vois pas en quoi un getter/setter serait plus sécurisé.</p>Question sur l'encapsulation des attributs, message #562592015-05-10T20:10:54+02:00felko/@felkohttps://zestedesavoir.com/forums/sujet/3117/question-sur-lencapsulation-des-attributs/?page=1#p56259<p>Salut,</p>
<p>Je code avec un ami un jeu en C++, et nous ne sommes pas d'accord sur un point, du coup on fait appel à votre expertise pour trancher. Notre problème est un sujet récurrent sur les forum, mais à chaque fois la question déclenche souvent des émeutes, j'espère que ça ne sera pas le cas ici <img alt=":)" src="/static/smileys/smile.png"> . Dans tous les cours de C++ que j'ai pu lire, il est conseillé de mettre tous les attributs en <code>private</code> et d'éventuellement mettre des <em>getter</em> et <em>setter</em>. Ayant appris la programmation avec Python, je n'ai pas beaucoup de notions en encapsulation. Voici notre classe:</p>
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre> 1
2
3
4
5
6
7
8
9
10
11</pre></div></td><td class="code"><div class="codehilite"><pre><span class="k">class</span> <span class="nc">Rect</span>
<span class="p">{</span>
<span class="k">public</span><span class="o">:</span>
<span class="n">Rect</span><span class="p">(</span><span class="n">Position</span> <span class="n">pos</span><span class="p">,</span> <span class="kt">int</span> <span class="n">w</span><span class="p">,</span> <span class="kt">int</span> <span class="n">h</span><span class="p">);</span>
<span class="n">Rect</span><span class="p">(</span><span class="kt">int</span> <span class="n">x</span><span class="p">,</span> <span class="kt">int</span> <span class="n">y</span><span class="p">,</span> <span class="kt">int</span> <span class="n">w</span><span class="p">,</span> <span class="kt">int</span> <span class="n">h</span><span class="p">);</span>
<span class="o">~</span><span class="n">Rect</span><span class="p">();</span>
<span class="n">Position</span> <span class="n">pos</span><span class="p">;</span>
<span class="kt">int</span> <span class="n">w</span><span class="p">;</span>
<span class="kt">int</span> <span class="n">h</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
</td></tr></table>
<p>Mais Qames (celui avec qui je code le projet) me dit de mettre les attributs en <code>private</code> et de faire des <em>getter</em> et <em>setter</em>, sous prétexte que c'est plus sécurisé. Mais si le code des accesseurs sont "classiques" c'est à dire <code>T getAttr() { return attr; }</code> pour le <em>getter</em> et <code>void setAttr(T val) { this->attr = val; }</code> pour le <em>setter</em>, alors à quoi bon ? Ca revient au même, non ?</p>
<p>Merci d'avance,</p>
<p>AZ et Qames.</p>
<p>PS: Pour une classe aussi simple c'est pas plus facile de faire une <code>struct</code> ?</p>