mageekblog - Mot-clé - protected - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearprivate, protected et public sont dans un bâteau... - mageekguyurn:md5:2cddf70b629ae611b7bb11081b47442f2010-12-30T13:28:45+01:002010-12-30T13:29:52+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2565" rel="nofollow">Eric</a> : Et tu fais quelle distinction entre cela et un appel à une méthode de la classe <code>A</code> qui modifierait la propriété <code>a</code> dans la méthode de ta classe <code>X</code> ?</p>private, protected et public sont dans un bâteau... - Ericurn:md5:b19f09bec7af80f12c4ad3404402c5a42010-12-30T11:32:43+01:002010-12-30T13:29:52+01:00Eric<p>class A {<br />
public $a;<br />
}</p>
<p>class X {<br />
function f1(A $a){<br />
$a->a = 3<br />
}<br />
}</p>
<p>$a = new A();<br />
$x = new X();</p>
<p>$a->a = 42;<br />
$x->f1($a); //L'attribut $a->a est modifié de manière subtil et inattendu (comme une fonction qui modifierait une variable globale)</p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:9759070a061b6a17a22ed27d40d7b1672010-12-30T10:09:17+01:002010-12-30T10:10:38+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2563" rel="nofollow">Eric</a> : Une propriété publique est une variable globale ? Uh ? Je dirais même : <abbr title="What The Fuck ?">WTF</abbr> ?</p>private, protected et public sont dans un bâteau... - Ericurn:md5:ee581592757b28f93b9d0b465bdb30502010-12-30T07:11:59+01:002010-12-30T07:12:42+01:00Eric<p>Cette conversation est extrêmement intéressante.</p>
<p>Pour répondre à la motivation de la suppression de l'héritage : non, je ne suis pas repassé en procédurale (j'ai essayé pour voir, mais le résultat n'est pas bon). J'utilise désormais principalement la composition. Cela suffit dans la majorité des cas **dans le développement web**. Cela me permet en générale de *trouver* des structures plus petites et beaucoup plus stables qui peuvent me resservir partout, ce que ne permet pas de faire un arbre d'héritage complexe.</p>
<p>Un autre truc : un attribut public, c'est un autre nom pour une variable globale <img src="/themes/default/smilies/wink.png" alt=";-)" class="smiley" /><br />
Un objet existe pour rendre des services, pas pour servir d'espace de stockage.</p>private, protected et public sont dans un bâteau... - Steufurn:md5:2f50c08ee7023688fd30a2332cb9f0cc2010-12-29T14:56:32+01:002010-12-29T15:02:32+01:00Steuf<p>Au final tout est une question de point de vu, là ça va même plus loin que la réflexion initiale. C'est un peu comme dans l'enseignement, chaque professeur a ses méthodes, qui sont plus ou moins bonnes :p</p>
<p>"je file des claques à la place :p " => moi j'ai une batte de Baseball au bureau (véridique), ça fait toujours son petit effet quand un nouveau arrive :p</p>private, protected et public sont dans un bâteau... - gabrielurn:md5:5fbd5574ee0f9641551e7853366ca2cd2010-12-29T14:23:29+01:002010-12-29T14:52:34+01:00gabriel<p>Bonjour,<br />
Je pense qu’il fait garder à l’esprit deux idées :</p>
<p>1 - L’encapsulation ne se préoccupe pas de ce qui est bien ou mal ni de ce qui est ouvert ou fermé, ni même de liberté ou d'élévation de son soi profond ...</p>
<p>2 – Une solution n’est valable que pour un problème identifié dans un contexte donné. Si mon problème et/ou mon contexte change, ma solution doit être étudiée à nouveau, avec modification ou non. Ainsi, comme personne n’est devin, on ne peut avoir que l’intuition de l’avenir mais aucune certitude et comme il faut bien avancer, des décisions sont prises, non pas les meilleurs mais les moins pires, c'est-à-dire celle qui font un poids moyen entre coût, qualité et délai.</p>
<p>J’affirme que beaucoup de développeur devrait garder cela en tête et qu’il vaut mieux avoir une production moins dans les règles de l’art (comprendre quelque chose qui hérite du « beau ») et plus dans les délais et la qualité, plutôt qu’un clone de l’essence de la perfection où l’on se doit d’attendre n fois plus de temps. Toutefois, si j’obtiens le beurre et l’argent du beurre je ne suis pas contre.</p>
<p>Je nomme cela « le bon sens allié à la réalité »</p>
<p>Ainsi, des biens pensants on introduit le concept de « refactoring », en réalité c’est juste un palliatif au remord, qui permet de revoir l’architecture d’un modèle afin de s’adapter au changement.<br />
Bref, on ne produit jamais l’application ultime mais juste des instances qui tendent vers le mieux. D’ailleurs des petits malins ont créé des versions (sombre agencement de main, major et minor realease accouplé à des builds number et alpha, beta, gamma release …)</p>
<p>"Le bon sens allié à la réalité " m’indique que je ferai toujours des erreurs (je l’accepte) mais que tant que ma solution fonctionne c’est déjà çà de pris. Toutefois, cela ne doit servir de prétextes à tout et n’importe quoi. Il y a certaines bonnes pratiques à respecter issues de l’expérience (la mienne ou celle d’autres comme moi) qui s’imposent de fait lors que le nombre de développeurs augmente dans et autour de mon projet et qui, finalement, me permette de faire moins d’erreur.</p>
<p>L’encapsulation (donc) implique deux notions : Responsabilité et Collaboration</p>
<p>- Responsabilité dans le sens où ma classe est responsable du traitement qu’elle propose.</p>
<p>- Collaboration dans le sens où ma classe peut plus ou moins consentir à travailler avec d’autres classes ou à laisser d’autres classes utiliser ses compétences afin de fournir un traitement alternatif/amélioré/spécialisé (héritage)</p>
<p>Ainsi, nous pouvons établir les principes de départ suivant pour un attribut ou une opération (nommé membre dans la liste) :</p>
<p>1 - si mon membre est à usage strictement personnel je le déclare private. Par exemple un $i dans une boucle for qui aurait besoin d’être visible dans d’autres opérations</p>
<p>2 - si mon membre est à usage personnel mais nécessaire à des classes filles, je le déclare protected</p>
<p>3 - si mon membre relève du principe 2 mais que sa non maitrise impliquerait un comportement aléatoire dans le traitement de ma classe, je le déclare private. A la rigueur, je fournirai un accesseur protected permettant de lire et/ou écrire son état. Ca pourrait être le cas d’un $i dans une boucle for qui a besoin d’être vu par plusieurs opérations, utile pour des classes filles mais dont la modification sauvage provoque un comportement instable. La classe ayant la responsabilité de son traitement, elle s’assure de son utilisation en fournissant un getter et/ou un setter protected.</p>
<p>4 - Si un attribut doit être utilisé à l’extérieur de ma classe, je le déclare public si, quelque soit sa valeur, il n’impacte pas la stabilité du traitement de ma classe. Je le déclare public. Par exemple, j’ai une classe qui passe en revue une collection et qui, pour l’élément courant, place ses valeurs dans des attributs publics. Ce que si passe à l’extérieur importe vraiment peu la classe car elle ne fait qu’écrire ses attributs. Par exemple, StreamTokenizer en java propose ttype, nval et sval qui contiennent des informations sur le token courant. Ces attributs sont public. Quelque soit ce qui est fait avec, cela n’impacte pas le fonctionnement de la classe.</p>
<p>5 - Au contraire, si un attribut doit être utilisé à l’extérieur de ma classe et que sa valeur peut avoir un impact sur mon traitement, je le déclare protected et je fournis des accesseurs public. Pour savoir si finalement, l’attribut doit être protected ou private, il faut étudier les principes 2 et 3.</p>
<p>6 - si une opération doit ou peut être appelé de l’extérieur de la classe je la déclare public, sinon il faut étudier les principes 2 et 3 pour savoir si elle doit être protected ou private</p>
<p>7 – si une opération ne demande pas d’état de mon objet (pas besoin d’avoir une instance), je peux (doit) le déclarer static. Ca peut avoir du sens pour fournir un traitement particulier sans avoir à instancier une classe. La visibilité est à étudier avec le principe 6</p>
<p>8 – il y a des cas où le résultat de mon traitement peut avoir des conséquences sur un comportement externe à ma classe. Autrement dit, un membre de ma classe utilisable à l’extérieur ou à l’héritage doit être sous contrôle car une (mauvaise) redéfinition impliquerait un comportement aléatoire à l’extérieur de mon traitement. Je le déclare final. Cela veut dire, je veux bien qu’on s’en serve mais c’est moi qui m’en charge car un mauvais résultat peut provoquer une instabilité à l’extérieur de ma classe. Prenons par exemple, java.lang.object qui est la classe de base de toutes les classes java (pour ceux qui ne connaissent pas trop, une classe java hérite de java.lang.object par défaut). Toutes les méthodes peuvent être surchargées. Par exemple, j’ai sûrement une autre vision de equals … Toutefois, les méthodes notify, notifyAll et wait sont public mais final. En effet, utilisée pour les threads une mauvaise redéfinition pourrait avoir un impact à l’extérieur de ma classe et rendre instable l’application complète. Si notify ne fait le travail attendu, un thread attends toujours même après l’appel de notify et le comportement global de l’application à partir d’ici devient très aléatoire. Son utilisation à bon escient a vraiment du sens. Définir un membre private et final ne sert à rien !</p>private, protected et public sont dans un bâteau... - samurn:md5:14284643cbc9722b248aa043031888d12010-12-29T12:50:55+01:002010-12-29T14:49:51+01:00sam<p>Je pense qu'il ne faut pas prendre les développeurs pour des idiots. L' "utilisateur final" est un développeur. J'ai beau être entouré de juniors à l'heure actuelle, j'ai banni les mots clefs "private" et "final" de mon code ( je file des claques à la place :p ). Si un dev veux surcharger une de mes classes, plutôt que de faire de la composition, libre à lui. Par contre, j'abuse du "protected".</p>
<p>De toute façon, aussi cloisonné que sera votre code, quelqu'un qui met les mains dedans transformera toujours votre application en une tchernobillette (aka usine à gaz) s'il ne sait pas coder/réfléchir.</p>
<p>C'est en partant de l'idée que les devs sont stupides qu'on a retiré l'héritage multiple dans les languages récents, avant même l'invention/démocratisation des mixins (ah, les traits, comme je vous attends... ).</p>
<p>La montée en compétence des développeurs ne peux pas se faire via un code restrictif: il pestera (on est des devs...) contre la restriction, et il commettra les erreurs qu'on lui a évité de faire la prochaine fois qu'il écrira sa propre classe from scratch.</p>
<p>A ma connaissance, tous les devs, (qui ont plus de 3 mois de code derrière eux) réfléchissent avant de surcharger une fonction protected. Mieux vaut très bien documenter sa classe, indiquer à chaque fois le pattern utilisé, etc..., et quand c'est faisable, guider les moins expérimentés d'entre nous.</p>
<p>Juste une petite exception au principe de protéger toutes les propriétés: lorsque j'utilise une classe comme une "struct" au sens C++ du terme, cad simplement une liste de propriétés, sans méthodes.</p>private, protected et public sont dans un bâteau... - Steufurn:md5:27bc1d9c3ae31ec3a5ca060ccaaaf0932010-12-29T12:44:04+01:002010-12-29T14:49:51+01:00Steuf<p>Une équipe sait toujours les nomenclatures, et répondra effectivement le pourquoi de celle-ci, mais personne n'est parfait, certains tics reviennent parfois et cela a parfois des conséquences indésirables qui ne sont pas vue à temps, de ce fait certaines structures de code "critiques" sont imposées par le code lui même permettant d'avancer sereinement. Et éviter de voir l'erreur trop tard car d'autres couches de codes son basé sur cette "erreur"... Après je suis d'accord avec toi dans certains contextes, dans le mien ici présent cet état d'esprit n'est pas jouable, certaines personnes doivent être cadrée car elles manquent de rigueur et quand on a un projet à mener, l’efficacité prime parfois sur d'autres aspects que tu mets en avant (dans notre contexte).</p>
<p>De la même façon je n'est pas mis en place une dictature non plus je ne suis pas comme ça <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /> Tout n'est cadré comme ceci, certaines choses le sont car les personnes ne doivent impérativement pas sortir de ce cadre, et je préfère avoir des systèmes de vérification que de devoir checker tout le code qui passe sous mon nez et renvoyer à l'expéditeur <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /> Tout le monde gagne du temps et de l’efficacité.</p>
<p>Il y a aussi une bonne dose de liberté dans le projet (sous réserve de validation bien entendu quand même, chaque prise d'initiative doit être justifiée), et il y a toujours du dialogue entre tous les collaborateurs. Les portes fermées sont minimes par rapport à celles qui sont ouvertes, mais certaines doivent pourvoir dans certains cas être fermées.</p>
<p>Mais ce sont nullement des restrictions, juste des "rappels à l'ordre". Et si le cadre prose problème c'est bien évidemment discuté et si c'est justifié le cadre est ajusté, on ne peut pas tout prévoir <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>
<p>Les stagiaires que j'ai eu sont toujours repartis en aillant appris beaucoup de choses, sur tous les niveaux <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /> (A coup de règles sur les doigts ils apprennent vites :p)</p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:63ce7754e4d41225e678cd91eafc6a442010-12-29T12:15:23+01:002010-12-29T12:24:12+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2543" rel="nofollow">Steuf</a> : <q>l'utilisateur n'aura jamais besoin d'un comportement autre</q>...</p>
<p>Tu es donc devin ;).</p>
<p>Réduire les libertés, en programmation ou dans tout autre domaine, est une mauvaise chose, même si cela est accepté par la communauté.</p>
<p>Oui, il faut des règles, des conventions, dans une équipe de développement, mais elles ne doivent pas devenir un carcan, et en conséquence elles doivent avoir un impact minimum, et le recours à <code>final</code> a pour moi un impact maximum.</p>
<p>La vrai évangélisation des bonnes pratiques ne passent pas par l'interdiction automatique par le système de faire ce qu'il ne faut pas faire, mais par le partage des connaissances, la pédagogie, l'enseignement, etc.</p>
<p>Dans ce cas, en tant qu'évangéliste, tu apportes une réelle valeur ajouté à ton équipe, car elle aura intégré les raisons pour lesquelles les choses sont faites ainsi.</p>
<p>Avec ton recours à <code>final</code>, le système se charge de réfléchir à leur place et joue le rôle de garde-fou.</p>
<p>Tu penses vraiment que cela les fait avancer, progresser, s'enrichir intellectuellement ?</p>
<p>Je n'en suis pas du tout convaincu.</p>
<p>Étant devin également à mes heures, tu vas certainement répondre que si tu poses la question aux membres de ton équipe, ils sauront parfaitement justifier l'utilisation de <code>final</code>, et cela ne peut être qu'une très bonne chose, mais dans ce cas, pourquoi l'utiliser puisque cela a un impact négatif à la fois sur l'évolutivité du code, que tu ne peux prédire tout devin que tu sois, et sur les tests ?</p>private, protected et public sont dans un bâteau... - Steufurn:md5:bb51a83c8fc8c013f08d1d393edfcd392010-12-29T12:08:13+01:002010-12-29T12:23:27+01:00Steuf<p>@mageekguy dans certains projets il vaut définir des règles qu'une équipe doit suivre ou mettre en place des éléments permettant de les suivre. C'est une nomenclature ici dans le sens ou il a été défini que dans un modèle get{ucfirst(properties)} permet d'accéder à la donnée brute "properties" de la base. Le nom de l'accesseur répond à une normalisation et faire un getName en faisant d'autre traitements ne répond plus à la normalisation et les développeurs n'ont pas le résultat souhaité à l'utilisation. Personne de mon équipe n'a jamais remis en question cette normalisation au démarrage du projet, au contraire ça simplifie la vie sur bien des plans.</p>
<p>Dans mon exemple l'utilisateur n'aura jamais besoin d'un comportement autre, c'est une nomenclature, et cela à permis à l'équipe de faire les choses de la même façon. Ce n'est pas un manque de confiance (enfin si un peu, dans la réalité tout le monde n'a pas le même niveau et la même rigueur... ha la rigueur un sujet passionnant...) c'est surtout que chaque développeur a ses "tics", ses "habitudes" et quand on travaille en équipe il faut que TOUS aillent dans la même direction sinon on se retrouve avec un "phpBB" avec un code à toute les sauces (à l'époque de la version 2) impossible à maintenir. Il est mieux de parfois mettre des pistes de rappel dans le code de certaines normalisations que de réagir après coup à la livraison que quelqu'un l'a "oublié" et que cela fasse capoter beaucoup de choses.</p>
<p>La confiance est une chimère quand on a une équipe et un projet à mener, il y a des règles stricts qui répondent parfois plus qu'à l'aspect stylistique, qu'elles soient bonnes ou mauvaises (personne n'est parfait, mais quand personne ne décide rien c'est l'anarchie). La normalisation et la mise en oeuvre de celle-ci ne fait jamais de mal, bien au contraire (d’expérience) .</p>
<p>Et en règle général je ne décide pas seul de ces nomenclatures et des mesures pour la faire respecter, elle sont discutées avec toute l'équipe.</p>
<p>J'avais comme toi cette vision d'ouverture, avant, mais à partir du moment où j'ai du gérer une équipe ma vision a un peu déviée par la force des choses pour mener à bien un projet.</p>
<p>NB: je ne suis nullement blessé, chacun à une vision, qui varie en
fonction des expériences. De la même façon ici personne ne sent un
manque de confiance avec ces "obligations" mais tout le monde le voit
comme une aide limitant les erreurs <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:2c9153db28be4e984b2fd2bd47d97d4c2010-12-29T11:39:08+01:002010-12-29T11:54:06+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2541" rel="nofollow">Steuf</a> :Et si ton utilisateur a effectivement besoin du comportement que toi, du haut de tes prérogatives de Dieu omniscient et parfait (car tu sais tout, tu as la Connaissance), tu as décidé d'interdire ?</p>
<p>Je comprend ta philosophie, mais elle suppose un pouvoir divinatoire que je suis loin d'avoir et elle reflète à mon sens un tel manque de confiance, voir un mépris, pour l'utilisateur final (sans mauvais jeu de mot) trop con pour savoir ce qu'il fait que je me refuse le plus catégoriquement du monde à y adhérer.</p>
<p>Par expérience, et je pense que je suis quelqu'un qui sait ce qu'il fait quand il code, final est une calamité, un frein, une horreur qui ne devrait pas exister qui bride la créativité et l'évolution.</p>
<p>À mon sens, cela va même à l'encontre de l'un des objectifs de la POO qui veut permettre au code de pouvoir s'adapter, changer, à moindre frais.</p>
<p>Attention, tout cela évidement lorsque final est appliqué sur une méthode publique (mais à y réfléchir, j'ai le même problème dans le cas d'une méthode protégée).</p>
<p>Sans compter que c'est une plaie dans le cadre des tests unitaires...</p>
<p>Et ne prend surtout pas mal mes remarques <q>ironiques</q>, elles ont pour but de faire ressortir très explicitement le problème que me pose ta stratégie et nullement de te blesser.</p>private, protected et public sont dans un bâteau... - Steufurn:md5:241e39e4988d538937a2d7bba14384ec2010-12-29T11:34:01+01:002010-12-29T11:39:00+01:00Steuf<p>@mageekguy Oui je m'attendais à ce contre exemple je m'en suis rendu compte en l'écrivant, on ne fait jamais comme cela et je suis parfaitement d'accord, ce qui est important c'est plus l'esprit.</p>
<p> Je n'ai pas sorti le cas concret car il dépend du contexte et c'est aussi une question de point de vu, car l'utilisation du mot clé final dépend beaucoup du contexte du code, du projet lui même et des personnes qui travaillent dessus. Cela s'applique plus aux accesseurs au final, du genre une classe représentant une ligne d'une base de donnée (un modèle) lorsque l'on veut la valeur de la colonne "name" et donc de la propriété "name" de l'objet on fait une méthode getName qui doit renvoyer la donnée brut, c'est mon point de vue dans ce contexte, en donc getName doit être "final".</p>
<p> Imagine qu'une deuxième classe qui hérite de celle-ci, on veut avoir cette propriété en majuscule, certains auraient tendance à réécrire getName en ajoutant un strtoupper, le nom de la méthode devient pour moi ambigu. Le fait de la définir en "final" obligera donc la personne à faire une nouvelle méthode qui portera un autre nom, comme par exemple getUpperName. Résultat on a orienté/obligé la personne vers une bonne pratique, à savoir nommer correctement des méthodes en enlever tout ambiguïté mais aussi à garder une nomenclature qui est ici : getName => Renvoi la valeur brute "name", getType => Renvoi la donnée brut Type etc.</p>private, protected et public sont dans un bâteau... - Steufurn:md5:a3efa2e294f618f45b03c64cc9b9c30a2010-12-29T11:14:48+01:002010-12-29T11:16:45+01:00Steuf<p>@Eric Se priver d'héritage est un peu "extrémiste" quand même, il faut l'utiliser à bon escient et lorsque cela a une réelle utilité (En fait quand on a clairement identifié des "objets" lors de la factorisation). Il y a des moment quand je regarde la structure de certains Framework je me pose des questions quand je vois à quel point ils abusent (à mon sens) de l'utilisation de l'héritage qui complexifie (et alourdi) quelque chose qui est sensé vous simplifier la vie à l'utilisation... Parfois c'est tout le contraire et pire, dégrade totalement les performances des applications pour pas grand chose.</p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:96ef8b0b1396fb6d1f0955d18ee6787b2010-12-29T11:12:13+01:002010-12-29T11:16:27+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2536" rel="nofollow">Steuf</a> : Ton exemple est l'illustration parfaite de la classe mal branlée :D.</p>
<p>Je m'explique.</p>
<p>Si tu veux des poires, il te suffit de le demander explicitement :</p>
<blockquote><pre><code><?php<br />...<br />function addPoire(\poire $poire) { ...}<br />...<br />?></code></pre></blockquote>
<p>Mais à mon sens, ta méthode devrait être plus générique et avoir la signature suivante : </p>
<blockquote><pre><code><?php<br />...<br />function addFruit(\fruit $fruit) { ...}<br />...<br />?></code></pre></blockquote>
<p>Comme tu l'as dit, ce n'est qu'un exemple, mais je le trouve judicieusement choisi pour démontrer que final est plus le symptôme d'un vice de conception que d'autre chose.</p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:4ef2dee11151bc7ac8890363b582217f2010-12-29T11:10:09+01:002010-12-29T11:12:05+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2537" rel="nofollow">Eric</a> : La comparaison n'est pas faite au niveau de la visibilité, mais par rapport aux avantages que le fait d'être ouvert apporte.</p>
<p>Et quand à ne plus utiliser l'héritage... tu es repassé en procédural ?</p>
<p>Parce que faire de l'objet sans utiliser l'héritage (correctement), c'est un peu inutile.</p>
<p>J'aimerais vraiment connaître ta motivation.</p>private, protected et public sont dans un bâteau... - Ericurn:md5:31166ecbfe2ec14eeb119e1d801372b42010-12-29T11:08:13+01:002010-12-29T11:10:04+01:00Eric<p>Je ne comprend pas la comparaison avec un format ouvert : on ne peut pas hériter d'un format ouvert. Le format ouvert défini la partie PUBLIC, l'implémentation est la partie PRIVÉE et n'est pas spécifié dans le format. Ou se situe le protected dans un format ?</p>
<p>(par ailleurs, j'ai décidé de ne plus utiliser l'héritage en PHP et je m'en porte beaucoup mieux, donc, exit le protected)</p>private, protected et public sont dans un bâteau... - Steufurn:md5:f0077d538fb7be91f0a4039a57278a832010-12-29T11:02:56+01:002010-12-29T11:09:39+01:00Steuf<p>@mageekguy Je ne dis pas qu'il faut l'utiliser à tout va ni que je l'utilise souvent.</p>
<p>De la même façon pour moi "public" ne signifie pas donnée "moins sensible" mais "Visible ou non à l'utilisation", que ce soit sensible ou non, d'ailleurs pour moi tout est sensible dans un objet :p</p>
<p>Imagine un muteurs qui permet d'ajouter une collection d'objets "Poire" à l'objet courant "SaladeDeFruit", qui serait du genre public addPoires($poires), qui vérifierait que tous les éléments sont bien des Poires et l'ajouterait à l'objet courant. Pour je permettrait à cette méthode d'être modifiée, permettant par la même occasion qu'un développeur la transforme en addPoires($prunes) ? Alors que ce muteurs fait une action des plus basiques qu'il soit ?</p>
<p>C'est un peu imagé et grossi, mais dans les faits il est parfois nécessaire d'imposer une finalité.</p>
<p>C'est mon point de vue, et le mot clé final n'est pas pour moi un signe de classe mal conçue mais plutôt une limitation parfois nécessaire, parce que la liberté c'est bien, mais elle s'arrête là ou commence celle des autres <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /></p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:ba8479c9ea71eb8753c50b39d5400ba62010-12-29T10:30:49+01:002010-12-29T10:41:34+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2534" rel="nofollow">Steuf</a> : <code>final</code> n'est effectivement pas très connu, mais ce n'est pas plus mal.</p>
<p>Il est en effet un réel problème pour mettre en œuvre les mocks, et de plus, de mon point de vue, il ne présente aucun intérêt au niveau des méthodes publiques.</p>
<p>Je suis en effet très curieux de savoir comment tu peux être capable de prendre la décision d'utiliser <code>final</code> sur une méthode publique.</p>
<p>Sur quoi te bases-tu ? Tu as une boule de cristal ? Tu vois l'avenir ? De quel droit oses-tu brider tes utilisateurs ? Comment peux-tu anticiper le fait que tes utilisateurs n'auront jamais besoin de bypasser ta méthode ?</p>
<p>Si elle ne doit pas être surchargée via l'héritage, c'est qu'elle est trop <q>sensible</q> pour être publique.</p>
<p>À mon sens, <code>final</code> est le signe d'une classe mal conçue, et il allume dans ma tête un énorme panneau clignotant sur lequel il est marqué <q>Attention, classe mal branlée !</q>.</p>private, protected et public sont dans un bâteau... - Steufurn:md5:e72a18f7a4d85433a0fe074f67142d562010-12-29T10:27:15+01:002010-12-29T10:30:23+01:00Steuf<p>Je pense que ce débat est un peu plus vaste que l'encapsulation qui est une solution limitée dans certains cas et dans l'esprit de <q>Qu'est ce que les développeurs peuvent utiliser, hériter, faire et réécrire</q>.</p>
<p> L'encapsulation c'est surtout essentiel à l'utilisation de la classe en question : Lorsque que j'instancie cet objet, à quoi j'ai accès ?</p>
<p> Pour moi tout ce qui est visible c'est les points d'entrée, et les points de sorties ce que tu identifie avec les TDD, au final.</p>
<p> Pour ce qui est des propriétés, personnellement je met tout au minimum en <code>protected</code>, pour moi une propriété à l'utilisation de l'objet ne peut être modifiée à la "volée", toute modification/lecture d'une propriété d'un objet doit se faire via des accesseurs/muteurs, permettant d'avoir un contrôle total sur les points d'entrée et faire les vérifications de données en entrée (Type de donnée, limitation de données etc) et non pendant l’"exécution", une erreur de donnée doit pour moi être identifiée le plus tôt possible dans un script. Tout autre méthode relatives à des traitements "internes" à la classe sont quand à elle protected et private.</p>
<p>Après les limitations d'utilisation de la classe, il faut gérer les limitations que l'on souhaite appliquer à l'héritage, or ici l'encapsulation n'offre pas une solution complète car il peut arriver que l'on ait besoin qu'une méthode soit visible à l'utilisation (<code>public</code> donc) mais que sont comportement ne puisse pas être modifié et ne doit pas pouvoir être réécrite via l'héritage.</p>
<p>Dans ce cas, l'encapsulation ne permet pas de répondre à ce besoin, ce qui est le rôle du mot clé "final" qui a toute son importance et permet de répondre au besoin. Et étrangement je trouve qu'il est plutôt très peu (méconnu ?) utilisé des développeurs PHP...</p>
<p>Voilà pour ma contribution sur le débat qui va plus loin pour moi que l'encapsulation.</p>private, protected et public sont dans un bâteau... - mageekguyurn:md5:d48307e2b1dbc0ba5c03132b9ccbce232010-12-29T10:03:22+01:002010-12-29T10:06:30+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/12/28/private%2C-protected-et-public-sont-dans-un-b%C3%A2teau...#c2532" rel="nofollow">speedyop</a> : Ne me fait pas dire ce que je n'ai pas dit.</p>
<p>En effet, je n'ai jamais dis qu'il fallait s'exposer inutilement, bien au contraire, mais au maximum, en fonction des contraintes imposées par l'implémentation réelle de la classe et les cas d'utilisation concrets apparus lors du TDD.</p>