mageekblog - Mot-clé - POO - 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:26874ca5b8cd4cac8d08b0e68e64f63aDotclearJ'ai oublié de vous dire… #1 - mageekguyurn:md5:c6712dbfdc6b3aef1f1e885730f091292015-10-28T08:30:08+01:002015-10-28T08:31:07+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2015/10/28/J-ai-oubli%C3%A9-de-vous-dire%E2%80%A6-1#c7013" rel="nofollow">Ric Ochet</a> : C'est une habitude pour moi de faire ce genre de chose (et en cherchant bien, tu pourrais peut être même déjà la trouver, cette fameuse histoire ;)).</p>J'ai oublié de vous dire… #1 - Ric Ocheturn:md5:0372ce9af6136c613acf53e579dd94e32015-10-28T08:26:01+01:002015-10-28T08:26:01+01:00Ric Ochet<p>Bonjour,</p>
<p>J'aimerais bien y être mais je suis à 10.000 km de la France et j'aimerais savoir si vous ferez un article expliquant cette histoire intéressante que je souhaiterais bien connaitre?</p>
<p>Merci et bonne conf pour demain.</p>La POO expliquée par Steve Jobs - gregurn:md5:400f8c6cbfe0e9734430b12162bad4db2013-03-13T16:09:28+01:002013-03-13T16:42:32+01:00greg<p>Tant qu'a faire :<br />
$('.post-content').append('<div class="source"><a href="http://blog.mageekbox.net/?post/2013/03/12/'+ $('blockquote').attr('cite')+'">'+$('blockquote').attr('cite')+'</a></div>');</p>
<p><img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>La POO expliquée par Steve Jobs - raphaelleurn:md5:76de91759c2074414a6ec807102245132013-03-13T10:46:33+01:002013-03-13T10:53:50+01:00raphaelle<p>je suggèrerai tout de même un:</p>
<p>$(post-content).append('<div class="source">'+ $('blockquote').attr('cite')+'</div>');</p>
<p>pour une meilleur lisibilité <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>La POO expliquée par Steve Jobs - raphaelleurn:md5:e3d63c70a21743025185c16da0ab46752013-03-13T10:38:06+01:002013-03-13T10:53:50+01:00raphaelle<p>c'est la seule bonne réponse possible, rien à redire ! :p</p>La POO expliquée par Steve Jobs - mageekguyurn:md5:fea4d3aa0e837db3ed7c9a83bd9af7512013-03-13T08:48:35+01:002013-03-13T08:48:59+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2013/03/12/La-POO-expliqu%C3%A9e-par-Steve-Jobs#c4873" rel="nofollow">raphaelle</a> : Oui, je sais, j'exagère… mais j'en avais tellement envie, je ne suis pas parvenu à résister <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>La POO expliquée par Steve Jobs - mageekguyurn:md5:11d56bb1c817d3c2269af3871dd17f892013-03-13T08:47:10+01:002013-03-13T08:48:18+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2013/03/12/La-POO-expliqu%C3%A9e-par-Steve-Jobs#c4873" rel="nofollow">raphaelle</a> : <code>alert($('blockquote').attr('cite'))</code></p>La POO expliquée par Steve Jobs - raphaelleurn:md5:e4e343a5635e013a541b51a6afbdf1402013-03-13T08:24:09+01:002013-03-13T08:46:54+01:00raphaelle<p>Bonjour,</p>
<p>merci pour cet extrait, très explicite. Pourrais-tu nous donner sa source s'il-te-plaît?</p>private, 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>