Cette Habitude Peut Ruiner Tout Ton Code

Si tu souhaites devenir un expert de Python et apprendre à créer un code exceptionnel : developerssecr...
Si tu veux rejoindre une communauté de développeurs actifs et motivés : / discord

[@RealNeaRox]

si t'es intermédiaire et que tu fais ça c'est que tu n'es pas intermédiaire hahaha

[@sylvereleipertz955]

Tu ne peux pas te dire intermédiaire si tu fais ce genre de structure

[@codeavecdave]

Complètement d'accord et pourtant je connais des développeurs professionnels qui font ça

[@cedric2452]

Utiliser un dataclass ou pydantic cest top aussi

[@codeavecdave]

C'est un moyen simple et super efficace de résoudre ce problème oui

[@xaviercombelle4316]

on est pas en java, please no getter et setter.

[@xaviercombelle4316]

pas de membres privés, neither. Still, on est pas en java

[@codeavecdave]

Pourquoi ?? Je suis curieux d'avoir ton avis. C'est des fonctionnalités de POO pas de java

[@anyone3807]

On va nuancer un peu des 2 côtés : -> La POO fonctionne différemment dans tous les langages. Tant dans les concepts que dans la philosophie. Donc effectivement l'argument "c'est juste de la POO" n'est pas valable puisque ce n'est pas comparable -> Effectivement en Python on ne met pas systématiquement en "privé" (et on ne met pas en privé avec un double underscore pitié) -> Ça ne veut pas dire qu'on ne doit jamais utiliser l'encapsulation non plus. Les propriétés et descripteurs ne sont pas là pour faire joli. -> Donc on "met en privé" s'il y a information sensible et SURTOUT s'il y a vérifications des valeurs

[@codeavecdave]

​@@anyone3807 Merci beaucoup pour ton avis, mais j'avoue que je ne le partage pas du tout L'encapsulation est un concept fondamental de la POO, ça n'a pas vraiment de sens de penser que c'est individuel à chaque langage. Mettre un attribut en privé n'est pas non plus réservé à un langage de programmation, ça arrive lorsque comme tu l'as dis on a des vérifications de valeur à faire ou pour n'importe quelle autre raison où l'accès à cette donnée pourrait être mauvais. Quand tu commences à développer des projets assez gros, tu comprends que l'encapsulation peut vraiment aider à baisser le couplage et augmenter la cohésion de ton composant. Les propriétés sont une fonctionnalité exceptionnelle qui permettent de mettre en place de l'encapsulation sans avoir à utiliser une syntaxe de fonction. Comme tu l'as dis, elles ne sont pas là pour faire joli. Tu peux les utiliser pour créer des attributs dynamiques ou plus souvent pour encapsuler des données puisque ce sont des descripteurs avant tout J'ai regardé le lien que tu as envoyé par rapport aux simple et et doubles underscores pour les variables privées et à vrai dire ça ne change pas grand chose. On mets uniquement un underscore lorsque l'attribut est protégé et donc accessible uniquement dans la classe où se trouve l'attribut et dans ses filles. On en mets deux lorsqu'elle est vraiment privée c'est-à-dire accessible que dans la classe où se trouve l'attribut. C'est pour ça qu'on a du name mangling, pour qu'il n'y ait pas de problème si on veut définir un attribut avec le même nom dans la classe fille. J'aime beaucoup ce genre de commentaires parce que je pense que ça peut aider d'autres développeurs qui ont encore du mal avec la POO. Si tu souhaites un peu mieux comprendre l'orienté objets et surtout l'encapsulation du coup, je te conseille d'aller lire Object Thinking de David West et Elegant Objects de Yegor Bugayenko. Ce sont deux pépites qui permettent de comprendre beaucoup mieux la philosophie orientée objets et comment l'appliquer dans nos projets. Merci encore pour ton message ;) !

[@anyone3807]

Je n'ai pas dit que l'encapsulation était indivuduel à chaque langage mais que la POO fonctionnait différemment. Les concepts et les bonnes pratiques ne sont pas du tout les mêmes. - Dans certains langages on a les interfaces, en Python y a pas - Dans certains langages on a l'héritage multiple et pas dans d'autres - Dans certains langages on a les attributs protégé et pas dans d'autres et quand il y est, leur fonctionnement n'est pas le même - Dans certains langages on a les traits et pas dans d'autres - Dans certains langages on utilise des design pattern qui sont contre-productifs dans d'autres... Après oui, il y a des concepts qu'on retrouve un peu partout mais selon les langages, la POO s'éloigne plus ou moins de UML. Il y a même certains langages ou la POO ne fonctionne pas avec des classes mais avec des prototypes. Un argument que je vois beaucoup trop souvent de la plupart des devs source de mauvaises pratiques "La POO (dans le sens traditionnel UML) prime sur les bonnes pratiques du langage". sauf que non, dans le cas où c'est faisable, c'est à cause de ça qu'on se retrouve par exemple avec des devs java qui font des getter et des setter partout qui ne font que renvoyer/modifier un attribut (en gros qui ne sert à rien) sans même utiliser les propriétés. Les propriétés sont un mécanisme mis en place par Python pour permettre de faire de l'encapsulation selon la philosophie du langage. Je ne comprends absolument pas quand tu dis "encapsulation sans fonction". Tu as une syntaxe alternative qui te permet de faire justement ceci sans decorateurs avec la fonction property. Non ce que tu dis est absolument faux, la notion d'attribut protégé n'existe pas en Python. Tu peux retourner la doc officielle et la PEP 8 dans tous les sens, absolument personne n'en parle. Ça c'est juste une idée reçue venue de développeurs d'un autre langage qui ont voulu recalquer leurs concepts en Python. Au contraire Python a toujours été contre les attributs protégés. Comme quoi même les "experts Python" n'ont même pas toutes les informations. Je t'ai mis la PEP 8 des conventions officielles de Python qui explique noir sur blanc que les attributs privés sont précédés d'un seul underscore et tu arrives encore à me contredire sur ce sujet en me disant que ca se fait avec un double, c'est une preuve que soit tu n'as pas lu ce que je t'ai envoyé, soit tu fais preuve de mauvaise foi puisque c'est un classique chez les développeurs de ne pas se remettre publiquement en question. Et non, la surcharge d'attribut n'a absolument aucun rapport avec les attributs privés. Je ne vais pas être hypocrite. Je déteste prendre de mon temps pour faire un gros pavé pour expliquer quelque chose à quelqu'un, donner des ressources dont certaines officielles pour appuyer mon argument et me faire contredire sur des points qui sont objectivement faux et recevoir des conseils derrière basé sur un sentiment de superiorité "eh tu t'es trompé mais c'est pas grave, lis ça et tu comprendras tout autant que moi". Vraiment désolé cependant pour mon ton virulent. Et je te remercie également pour le temps que tu as pris ainsi que pour les livres. Moi je vais m'arrêter là. Peut être que tu m'en voudras pas trop. Que tu sois d'accord avec moi ou non, j'ai dit tout ce que j'avais à dire et continuer ne serait qu'une perte de temps pour nous. Bonne continuation

[@ilian572]

Mouais, Déjà je doute que les listes et dict soient des primitive Aussi, je ne vois pas le problème d'utiliser un dictionnaire pour représenter une ville ou une personne

[@codeavecdave]

Un dictionnaire en python est un mapping donc simplement une représentation des données sous forme clé-valeur, c'est simplement une structure de données. Ce n'est pas comme en TS où les dictionnaires peuvent être utilisés comme des objets

[@ilian572]

@@codeavecdave et donc ?

[@emelineclank9448]

​@@ilian572 ce n'est pas une faute en soit de représenter une ville via une structure. Mais disons que c'est généralement plus adapté d'avoir une class, dans la mesure où un système complexe comme une ville peut nécessiter l'ajout de fonctionnalités supplémentaires, ou devoir hériter de système parents (comme un système plus général qui s'appelle : ville) De même, l'allocation mémoire entre une struct et une class n'est pas la même, en tout cas en c++, je ne sais pas pour python. Représenter des floats, int, str : struct Représenter des objets complexes (voiture, avion, ville, personne...) : class

[@ilian572]

@@emelineclank9448 parfois un dictionnaire suffit

[@emelineclank9448]

@@ilian572 absolument. Généralement, c'est lorsqu'il n'y a aucune méthode associée au code. Je pense que l'objectif de sa vidéo, est de pointer du doigt ceux qui oublie l'existence des class. Comme certains débutant qui utilisent des dict, et font du traitement de la donnée sur le dict. --> les classes sont faites pour ça. Mais tu as raison. De toute manière, une classe est un dictionnaire quand on creuse alors bon ...