Ça c’est un véritable « game changer » 👍 Merci Simon pour tes vidéos toujours ultra pertinentes et efficaces 🙏
@danielleblanc5923
11 ай бұрын
L'idée de départ de du codage orienté objet c'est d'introduire une corrélation (très) forte entre des valeurs et les règles qui les accompagnent avec la logique suivante: - Si j'utilise des valeurs primitives (int, float etc...) je suis obligé de vérifier en permanence que la variable ne contient pas une valeur illégale (application des contrats de fonctions). - Si les règles de validité sont attachés à la valeur puisque regroupé dan la même classe, alors je n'ai plus besoin de faire ces vérifications à tout bout de champ, j'ai "déporté ou délégué" cette vérification dans la classe. Ceci a aussi pour but d'augmenter la réutilisation de code: les 10 fois où je fais plus la vérification sont remplacés par du code écrit et validé une seule fois. En plus, les fonctions / méthodes de comparaison permettent des économies de code. Si je n'ai pas de méthode de comparaison (par exemple x.compareTo(y)) et que je veux trier les éléments, je suis obligé de le faire à la main. Si par contre il y a un ordre dit naturel (ordre alphabétique pour des chaines de caractères) mis en oeuvre par une méthode de comparaison, il suffit d'introduire l'objet dans un "set" qui va trier les éléments à l'insertion. En suite on peut aller chercher ces valeurs dans l'ordre en parcourant le set. En quelques sortes le tri vient en bonus lorsqu'on met en oeuvre toutes les méthodes de comparaison ainsi que les méthodes de construction de clé (hash()). Il y a donc d'innombrables avantages à utiliser des objets au lieu de valeurs primitives. C'est aussi indispensable pour pouvoir avoir une valeur "complexe" comme retour de fonction, et éviter le recours aux variable globales.
@othelarian
9 ай бұрын
Ce que vous dites est pertinent, sauf que ce n'est pas le dév orienté objet mais la programmation fonctionnelle et la programmation par contrat qui portent ces principes, et non la POO. La POO à l'origine sert à fournir un comportement à des valeurs, et non la délégation de la validation. On retrouve d'ailleurs des problèmes inhérents à l'héritage qui viennent de l'application des principes de la POO et qui vont à l'encontre du principe de validation (par exemple l'incapacité de transfert de l'égalité, ou encore les aberrations de fonctionnement suite à la modification d'attribut interne ou de composition multiple). Donc non, la liaison valeurs/règles ce n'est pas de la POO. Le Eiffel, le rust et le Haskell le démontre très bien sans utiliser d'objet. Et pour bien voir à quel point ce n'est pas lié (la POO et la validité) il suffit de prendre l'exemple du dégradé java/kotlin/scala. L'objet c'est avant tout une histoire de comportement, pas de validité. La POO a d'autres intérêts, mais pas ceux-là.
@michelph5206
9 ай бұрын
C'est très bien dit ! Seulement on doit s' evertuer a maintenir une balance entre performances et congruence, car les objets consument beaucoup plus de mémoires (RAM) que les types simples. Mais je partage ton point de vue, elle est correcte.
@KokahZ777
11 ай бұрын
Pourquoi pas utiliser une enum BanknoteValue en paramètre du constructeur pour éviter d’envoyer une exception ? On pourrait même envisager un Banknote par devise avec son enum associée
@Hadrazazel
11 ай бұрын
C'est une implémentation comme une autre, mais tu n'as pas intrinsèquement de validation accrochée à ton Enum. Ceci dit, si ensuite les transactions passent toutes par une API bien définie et qui fait ces validations c'est tout à fait envisageable. Autre désavantage, tu n'as pas du tout la possibilité de réagir à des changements sur tes Enums sans passer par une màj code. Ce qui peut être rédibitoire. Bon c'est pas commun mais si un pays ajoute ou supprime une valeur de billet, ça peut être cool de pouvoir mettre à jour la liste des billets valides en passant par une màj data. Les Banknotes ici présentés pourraient être décris par une configuration externe (distante ou locale) et ils suffirait de màj cette configuration sans toucher à l'éxécutable. Tout est une histoire de compromis.
@Trinita1970
11 ай бұрын
L'inconvénient c'est quand même la place que ça prend dans la mémoire par rapport à une valeur primitive.
@mrmaxwell0701
11 ай бұрын
Bravo pour cette vidéo , c'est vraiment courageux d'expliquer comment tu as su te remettre en question pour mieux progresser plutôt que de te braquer. 2 choses: - Même si je suis de ton avis concernant les Value Object (je les ai découvert via le Domain Driven Design) , la plupart des équipes avec lesquelles j'ai travaillé argueront que cette modélisation est trop complexe. L'effet est encore plus garanti dans le cas de l'utilisation d'un ORM car il faudra anticiper la sérialisation / désérialization des objets lors de l'écriture /lecture en base de données. - Je constate a travers ton vécu sur la POO que la faillite de l'éducation dans notre domaine provoque a plus long terme un rejet massif de méthodes pourtant éprouvées par une grande partie des professionnels qui chercheront à élaborer des solutions de contournement et ça, ça m'inquiète beaucoup.
@soufieneouertani3177
11 ай бұрын
tu peux aussi tout simplement utilisr une *énumération* et la variable en *final* Créer des objets c'est très consommateur de mémoire. ..surtout en java car tu maîtrise pas la destruction des objets comme en C++, il faudra éviter au maximum de créer des objets
@TheNeferith
Жыл бұрын
Avis, interessant. Après pour ce qui est de la fac, je constate quand meme souvent un écart de reflexion entre les devs qui sortent de la fac et ceux qui viennent d'ailleurs. Le travail purement théorique n'est pas inutile.
@ghostsngoblins6894
5 ай бұрын
Sortir de l'université ne garantit pas automatiquement la compétence. Dans tous les domaines, l'expérience pratique prime souvent sur la formation académique.
@adriencbl
11 ай бұрын
Les affirmations au debut jai du mal. Si un développeur nest pas capable de connaitre des principes theorique s sans son IDE il ne pourra pas facilement progresser. Il est necessaire de comprendre des principes (encapsulation, polymorphisme, SOLID, Microservice) sans les coder. Par exemple en sappuyant sur du UML. De plus pour lexemple du billet de banque lerreur est faite par ceux qui sont que sur leur IDE. Une personne qui connait le fonctionnement de Integer il comprebdra le probleme sans code
@blitz3128
11 ай бұрын
Comme toujours tout dépend du problème posé, comme tu le dis en substance car en POO et programmation en général nous travaillons sur une abstraction de la réalité. De plus, attention à ne pas tomber dans de "l'hyper-description" qui complexifiera le code, minimise la résilience de l'application finale dans le temps, augmente potentiellement les bugs pour rien, sans compter le temps perdu et l'alourdissement en mémoire de l'applicatif bien au delà du nécessaire. Par exemple, d'un point de vu technique et contrairement à une idée reçue, les règles d'une adresse email valide ne sont pas aussi contraignantes que ce qui est implémenté dans certaines applications.
@vynza
11 ай бұрын
En résumé. - un architecte logiciel sait faire la conception/modélisation du besoin. Mais en même temps, c'est une compétence de base d'un architecte digne de ce nom. - les modelisations ne dépendent pas du langage utilisé (orienté objet ou pas). Un tableau blanc ou un cahier est suffisant et une modélisation peut être implementé dans tous les langages permettant de faire des structures. - Qu'il ne faut pas passer tous les paramètres un par un sous forme de type primitif. Quelques soit le langage, il y a toujours moyen de créer des structures pour implémenter le datamodel, alors il faut s'en servir. Ou sinon, autant retourner en 1970 et faire de l'assembleur. MAIS par contre, créer une classe ou structure pour définir un mail qui n'aurait qu'un champ String, c'est con et ça rend les choses inutilement compliquées. A la rigueur, ça peut impressionner un chef qui ne s'y connait pas trop et gonfler l'ego d'un architecte veut paraitre plus intelligent qu'il ne l'est. Si je tombe sur un archi qui modélise une adresse mail avec juste une string, ou un solde client par une liste de billets, c'est un gros red flag.
@DystoKhan
11 ай бұрын
Clairement sur les deux derniers exemples, on perd en lisibilité et performance. C'est de l'abstraction non nécessaire. Sauf dans une appli de banque. Et même avec un GC, on perd en performance parce que l'allocation et l'optimisation d'une classe qui hérite d'une classe abstraite, c'est pas la même chose qu'une primitive. Mais encore faut-il s'intéresser à la perf.
11 ай бұрын
@@DystoKhan Premature optimisation is the root of all evil cependant...
@TheGaston33
11 ай бұрын
La question n'est pas de comment est implémenté la classe/type email mais bien le fait de mettre en place du typage fort vs de la primitive obsession pour obtenir un code expressif en lien étroit avec le domaine métier qu'il modélise.
@TarikMoustahsane-n9z
11 ай бұрын
Aucune valeur ajoutée dans votre discours bla bla bla
@superwaper2791
11 ай бұрын
Du coup plutôt que d'utiliser number, dans le paramètre du create, pourquoi ne pas faire un enum des valeurs uniquement possibles ? plutôt que throw une erreur ? Pour moi il suffisait de passer du Javascript au Typescript en typant et c'était plié.
@Bob2ld
11 ай бұрын
Un enum de BankNote suffit.. je dis ca, je dis rien ^^
@ChibiBlasphem
Жыл бұрын
Un peu dommage de ne pas parler des enum avec qui permettent d'avoir un set fermé de valeur
@KokahZ777
11 ай бұрын
Oui mais à moins de déclarer ta variable comme constante rien ne t’empêche de transformer un billet de 10 en billet de 20. Le mieux c’est d’enforcer l’immuabilité
@ChibiBlasphem
11 ай бұрын
@@KokahZ777 Et rien n'empêche de cumuler les deux, je parlais des enums vis-à-vis des valeurs hardcoded
@CyrilNeko
11 ай бұрын
C'est fou comment tu passe 12 min à nous apprendre des choses sans nous montrer de code pour quelqu'un qui pense qu'on peut pas apprendre, sinon devant un éditeur :D Sinon, j'ai l'impression que tu defends un choix arbitraire parmis d'autres. Mais c'est très interessant. Je ne pense pas que ça soit bien adapté au javascript, si tu fais des objets partout ; surtout avec des classes. Je préfèrerai des objets simples, identifiés par les interfaces qu'ils implémentent, et manipulées par des fonctions statiques. La fonction de comparaison est copiée dans chaque instance de billet... Une simple fonction exportée dans un fichier, et c'est réglé. Je me trompe ? Je suis peut être pas très à jour là dessus... JS, c'est pas des classes, c'est des "prototypes", non ? Dans tous les cas, ça n'invalide pas ce que tu dis sur l'encapsulation. Ca reste une bonne idée pour permettre un refactoring rapide. C'est top pour la compréhension et la maintenabilité. Merci du tuyau 👍
@nedjed4811
11 ай бұрын
Je ne peux que valider le fait de contrôler les valeur et d'avoir des objets spécifiant exactement la réalité. Par contre, je n'aime pas du tout l'approche pour un code en Typescript. Lorsque je voudrai créer un nouvel objet Banknote, la seule information que j'aurai est qu'il prend en param un number. Je pourrai donc créer un billet de 15, typescript n'y verra aucun problème. Le soucis ne sera visible qu'au runtime, et la c'est pour moi le problème fondamental de ne pas avoir typé les Input / Sortie de cette classe. De plus, un développeur arrivant sur le projet devra absolument regarder le code source pour voir les valeurs autorisées.
@Supremad
11 ай бұрын
Très mauvais exemple que celui du billet de banque qui n'a pas sa place dans une application quelle qu'elle soit. Personne ne fais ça. Tous les systèmes (banquaires ou non) sont basés sur des balances et des montants à plusieurs décimales. Bien qu'il soit vrai qu'implémenter de la logique de gestion dans les constructeurs des objets métier est un bon moyen de réduire les situations incohérentes, cela a un impact significatif sur les performances quand on passe à l'échelle. Prenez le en compte si vos apps doivent brasser des millions d'instances, vous risquez d'avoir de grosses surprises. Et pour l'immutabilité de vos objets/listes, scala vous le fait par défaut ;)
@othewisp
Жыл бұрын
En fait, le principe du value-object, c'est tout le principe de la programmation orientée concepts, qui est le paradigme qui correspond à notre manière de concevoir les choses et les représenter mentalement. C'était initialement le but de la programmation orientée objet, mais celle-ci n'a jamais réussi à s'abstraire de la machine et a mis en place des tonnes de mécanismes comme l'héritage qui ne font que très peu de sens dans 99% des cas. Pour citer Dijkstra : « La programmation par objets est une idée exceptionnellement mauvaise qui ne pouvait naître qu'en Californie. » « Les progrès ne seront possibles que si nous pouvons réfléchir sur les programmes sans les imaginer comme des morceaux de code exécutable. » Qu'il s'agisse de Java ou de Javascript, ou de n'importe quel autre langage mainstream, aucun ne parvient à proposer un niveau d'abstraction nécessaire. On est toujours obligé de dire à la machine ce qu'on veut qu'elle fasse plutôt que de simplement décrire les concepts que l'on veut mettre en œuvre et leur manière de s'imbriquer. Et aussi surprenant que ça puisse paraître, ça ne semble pas être la préoccupation de beaucoup de monde à part quelques poignées de chercheurs à travers le monde, alors que les bénéfices et l'impact sur le dev en général serait massif.
@codeursenior
11 ай бұрын
Hello, je ne connaissais pas la deuxième citation, elle est incroyable. La première citation ressemble à du troll. Pour la suite, ça me paraît être plus le domaine des chercheurs que de la réalité de l'industrie. Un peu septique sur la notion de décrire des concepts et leur manière de s'imbriquer entre eux. Merci pour d'avoir pris le temps pour le partage 👍 Bon code, Simon.
@othewisp
11 ай бұрын
@@codeursenior Haha oui il y a clairement un petit côté troll dans la première citation. Oui ça reste de la recherche pour l'instant, et pour avoir eu l'occasion de travailler sur le sujet, c'est clairement aujourd'hui à l'abandon. Mais c'est très paradoxal, parce qu'on voit chaque jour toujours plus d'outils "no-code" avec toujours plus ou moins de promesses, qui sont toujours plus ou moins tenues. Et donc on a d'un côté ces outils là qui permettent de faire certaines choses de manière relativement simple mais qui sont rapidement limités, et de l'autre côté les langages de programmation classiques qui n'ont aucune autre évolution que des petits ajouts (parfois très bien) mais sans se réinventer pour autant. Pour ce qui est de la description de concepts et de relations ça fonctionne très bien, mais ces langages ont besoin de s'interfacer nécessairement avec des choses plus bas niveau pour gérer les entrées/sorties.Techniquement ce sont d'ailleurs plutôt des langages machines de très haut niveau pour des machines virtuelles ;)
@elytes96
11 ай бұрын
@@othewisp C'est évident, plus on veut quelque chose de précis, moins le degré d'abstraction doit être élevé. L'abstraction et la généricité, ça ouvre la porte à l'ambiguïté. Il n'y a donc littéralement aucune solution à ça, ces deux mondes doivent exister indépendamment l'un de l'autre et on ne doit pas chercher de compromis parfait car celui-ci n'existe pas. Si je suis dans un langage de haut niveau, je m'exprime avec énormément d'éléments de langage différents qui ont chacun leur utilisation, mais à partir du moment où un élément du langage n'a pas la même signification pour moi que pour celui qui l'a inventé, je suis obligé de revenir à des concepts beaucoup plus primitifs. Si je suis dans un langage de bas niveau, je m'exprime avec très peu d'éléments de langage, mais au moins je suis certain de leur signification et j'ai donc un contrôle total sur la signification que je souhaite lui donner.
@othewisp
11 ай бұрын
@@elytes96 Par abstraction j'entends s'éloigner des considérations de la machine, ça ne veut pas dire généricité, au contraire les concepts doivent être définis avec une grande précision. La grosse majorité du dev actuel ça n'est justement pas de la précision, on ne fait que réécrire en boucle des choses qui ont été écrites des milliers de fois avant nous. Les applications qui font des choses qui n'ont pas été faites avant, qui ont des algos précis, des calculs complexes, ou qui ont besoin d'optimisations sont l'exception. Et dans ces cas là, bien sûr qu'il est nécessaire d'avoir des langages de plus bas niveau. Le problème c'est qu'aujourd'hui on a des langages et des bibliothèques qui nous font malgré tout écrire énormément de code, pour écrire des choses qu'on a nous même écrites des dizaines de fois et que milliers de personnes écrivent chaque jour, et que ces langages/bibliothèques de sont même pas optimisées en terme de performance, donc rien ne justifie qu'on écrive tant de code. Si par exemple tu développes une plateforme ecommerce sous laravel/react, tu vas vite te retrouver à écrire des milliers de ligne de code en cumulant le front et le back. Tu vas avoir des dossiers vendor et node_modules qui vont vite peser des dizaines voire centaines de Mio, le truc sera hyper lent parce que la plupart des technos sous-jacentes sont claquées et juste un empilement d'autres technos que personne n'a pris le temps d'optimiser. Il y a un souci. En tant que dev ce qui devrait m'intéresser c'est : - soit je fais du dev bas niveau, je crée des biblios, des outils pour les autres, donc là j'écris avec des langages qui s'adressent à la machine - soit je fais du dev "business level" qui répond à des attentes de l'utilisateur final, et là ce qui compte c'est d'implémenter la logique de l'utilisateur, donc des concepts réels (pour reprendre l'exemple de l'ecommerce : décrire ce qu'est un Produit, un Client, une Facture ...), je ne devrais pas avoir à me préoccuper de comment me connecter à la BDD, comment gérer l'upload des images, etc. Aujourd'hui c'est ce qu'il manque dans le dev. C'est qu'on va utiliser les mêmes langages pour faire différents niveaux d'abstraction au sein d'un même projet, parfois tout sera mélangé, et on réécrit énormément les choses. Le langage haut-niveau n'a pas nécessairement beaucoup d'éléments de langage différents, c'est à chacun de définir ses propres concepts (même si bien sûr le réemploi est toujours une bonne chose). L'idée est de s'abstraire de tout ce qui technique. Les concepts doivent uniquement correspondre à ce que l'utilisateur final est amené à manipuler.
@gaxkiller
11 ай бұрын
D'accords avec le propo global mais mauvais exemple. Si tu as des valeurs aussi restrictives, tu bloques à la création, faut pas que l'erreur aie lieu au runtime. Je fais pas de Java mais pourquoi pas un Enum pour les BankNote
@epiphanezongo7686
Жыл бұрын
Merci pour tes vidéos !!!! On voit vraiment qu'on doit pas laisser le code et on doit aller a fond même si c'est chiant des fois!!! je te suie depuis le Burkina Faso
@gaxkiller
11 ай бұрын
Pas bon ta classe BankNote -> le dev qui l'utilise a pas d'erreur avant le runtime. Pour le coup un enum avec value associée semble assez logique ici
@sandrine6466
9 ай бұрын
J'ai commencé une reconversion professionnelle dans le dév web et tes cours sont des pépites, vraiment pro senior, j'adore merci à toi d'élever le niveau.
@patrickloiseleur
11 ай бұрын
Et oui ça s'appelle encapsulation et c'est un pilier de l'orienté objet (l'autre étant l'héritage de type).
@danielmonteiro8124
11 ай бұрын
Et pour compter le nombre d'objets, on va utiliser une variable de type...
@syaPK
11 ай бұрын
donc car ca va prendre plus de ram et de cpu..
@quenti7728
11 ай бұрын
Faut éviter l'early optimisation, C'est préférable d'avoir un code lisible d'abord que opti. Bien sur si le travail est sur quelque chose qui demande d'avoir des opti il faut le faire mais la on parle vraiment de chose propre à JS et avoir 15, 20 nouvelle "class" en js seront toujours mieux que des code qui font des boucles d'appel de fonction pas opti :D
@zelastminute
11 ай бұрын
Pas sur que ce soit la meilleure idée d'associer chaque billet de banque par une instance d'objet... Je pense qu'il manque le contexte des cas d'utilisation derrière tes exemples. Qu'entends tu par "application bancaire" ? Un distributeur ? Une appli de gestion de compte ? Avant de modéliser, il faut d'abord comprendre le problème à résoudre.
@moafred666
11 ай бұрын
Overkill, un énuméré fait le même travail en plus lisible et plus performant. Enfin je suppose que le but était de parler du bon principe, l'exemple était peut être inadapté.
@psenej
10 ай бұрын
Les exams de code sur papier c’est ce qui m’a fait quitter la fac
@vitalite9610
Жыл бұрын
MOI je sui un vrai débutant j'ai beaucoup aimé l'explication Merci à toi Champion
@Trusty22
11 ай бұрын
Et maintenant tu vas lire "Array of structs vs struct of arrays" et tu sais plus quoi faire 😂 Belle vidéo! :)
@romaincoudray-r6m
7 ай бұрын
Merci énormément pour tes vidéos que je trouve extrêmement ludique 😉 Je viens de tomber sur ton profil "par hasard" et je suis assez bluffer sur le fait que je suis absolument d'accord avec toi Par contre juste pour cette vidéo, je suis d'accord avec toi sur les valueObject, juste je pense que pour certains cas c'est peut-être un peu overkill ? Donc selon moi uniquement, je ne pense pas que ce soit une pratique systématique. Mais je vais quand même essayer 😅
@codeursenior
7 ай бұрын
Salut, bienvenu sur la chaîne alors ! Pour les Value Objects, c'est un tactical pattern du Domain Driven Design. Autrement dit ? C'est uniquement adapté pour les projets qui ont une complexité métier très importante. Donc complétement overkill pour une application de type CRUD ou autre par exemple. 👍
@syliciumdev3195
11 ай бұрын
1:00 Javascript: *est un langage orienté objet* Simon: En javascript l'orienté objet on s'en fiche un ptit peu what- 🤣🤣
@codeursenior
11 ай бұрын
Pour ma défense : JavaScript est un langage orienté objet… basé sur les prototype… que personne ne maîtrise vraiment !
@julienr8114
11 ай бұрын
Contenu instructif même si je ne partage pas l'utilisation des class en javascript (Value Object). Une simple interface de mon point de vu fait largement le taff.
@codeursenior
10 ай бұрын
Salut @julien8114, je vois que tu as des réserves sur l’utilisation des Value Objects. Cependant, ils offrent des bénéfices significatifs qui méritent d’être pris en compte : 1. Validation de domaine : Un Value Object valide son état dès sa création, s’assurant que tu travailles toujours avec des données cohérentes et fiables, contrairement aux interfaces qui ne peuvent pas exécuter de logique de validation. 2. Immutabilité : Les VO sont immuables ; une fois créés, leur état ne change pas. Cela simplifie le debuggage et la prévisibilité de ton code, car tu n’as pas à suivre et maintenir l’état d’objet mutable. 3. Validation au runtime : Avec un VO, tu bénéficies de la validation au runtime, s’assurant que les données respectent les règles métier même après la compilation. Les interfaces TypeScript, elles, disparaissent à la compilation et ne peuvent pas offrir cette sécurité. 4. Cohérence et encapsulation : Les VO garantissent que toute la logique concernant les données est encapsulée avec elles. Cela force l’utilisation de méthodes définies pour interagir avec l’objet, évitant ainsi les manipulations d’état non contrôlées. 5. Sémantique riche et expressivité : Les VO portent des noms et des méthodes qui reflètent le domaine métier, rendant ton code plus lisible et compréhensible par rapport aux simples structures de données que les interfaces représentent souvent.
@JoeSchmo-z6l
11 ай бұрын
Sauf que pas besoin d une class pour ça. Une interface avec readonly en typescript fera pareil. La méthode create dans BankNote est pas top car pas solid. Il faudrait une factory pour créer les banknotes
@codeursenior
11 ай бұрын
Hello, pas tout à fait d’accord. Voici 2 inconvénients principaux d’une approche à base d’interface pour un Value Object : : • Pas d’encapsulation: Les fonctions liées à l’objet de valeur (comme equals) doivent être implémentées en dehors de l’interface, ce qui peut rendre le code moins organisé. • Pas de contrôle du constructeur: Vous ne pouvez pas imposer de logique de validation ou d’initialisation lors de la création de l’objet de valeur. Cela obligerai de mettre en place une Factory supplémentaire.
@olispirit6100
5 ай бұрын
Tu peux meme creer une banknotefactory et un banknotevalidator pour creer et valider ton pojo et ajouter une devise à ta banknote...attention de ne pas faire de l' over-engineering sur un projet. Les debutants tombent souvent dans ce piege en voulant trop bien faire.
@codeursenior
5 ай бұрын
Justement, l'histoire de la devise me donne envie de pousser encore plus loin le sujet ! 🔥 Et effectivement, l'over-engineering est tout aussi dangereux que le zero-engineering...
@mwlulud2995
Жыл бұрын
Rien que le début avec les interros sur feuilles est véridique!!!. J'ai eu pareil mais au collèges informatique ou j'ai eu pendant 1ans Java et mêmes la plupart des exercices etait aussi sur feuilles😅 Déja la syntaxe verbeuse,et l'obligation de POO me dégoute. Malgré cela jadore la POO avec php et javascript
@northerngannetproject3147
Жыл бұрын
L'OO c'est une façon de voir sin code... j'ai toujours pensé objet en faisant juste du C. Selectcolor( mypen,RED) C'est pareil que mypen.selectcolor(RED)
@hadibq
11 ай бұрын
Si pas de risque de besoin de faire de l'héritage et de la surcharge, c'est absolument inutile de passer par le raisonnement objet.
@codeursenior
11 ай бұрын
C’est faux il me semble. Objet = héritage…. (+ encapsulation + polymorphisme + abstraction). Il n’y a absolument pas besoin d’héritage, d’ailleurs préférer la composition plutôt que l’héritage, pour tirer les bénéfices de la programmation orienté objet.
@Xaalek
11 ай бұрын
Pour l'exemple du billet de banque c'est pas plus simple de faire une enum avec les valeurs 5, 10, 20 etc ?
@codeursenior
11 ай бұрын
Hello, non pas tant que ça pour 3 raisons : 1/ valeur dynamique de lAPI et du typage non géré au runtime. 2/ limitation : pas de getters encapsulé dans l’objet 3/ flexibilité : évolution du code, multi devise par exemple, impossible.
@mathieucaron4957
11 ай бұрын
Ça devrait être considéré comme la base... Ça me fait croire que le niveau est vraiment bas en France 😬
@sebsondej9868
11 ай бұрын
Subtile introduction au DDD par le bounded context 😉 bon boulot !
@codeursenior
11 ай бұрын
Merci à vous ! Bon code, Simon.
@Zidkdk223
11 ай бұрын
C'est une bonne idée de se lancer dans le DEV WEB en 2023 ? Ou c'est trop tard ?
@codeursenior
11 ай бұрын
Trop tard ? Vous pouvez réussir dans n’importe quelle industrie même si elle a plus de 100 ans, à condition d’être prêt à travailler dur. La question n’est pas trop tard, mais est ce que je suis prêt à travailler dur pour réussir dans ce secteur ?
@guedelplayer202
Жыл бұрын
"Immutabilité" c'est du franglais. En bon français je dirais "immuable", et en plus c'est plus court. Mais effectivement le concept est intéressant.
@manuelminana4826
11 ай бұрын
constant?
@BastienFacquet
7 ай бұрын
Bonjour, j'aime votre approche. Concernant la class Banknote je proposerais plutôt : class BankNote { const _10_ = 10; const _20_ = 20; const _50_ = 50; } Qu'en pensez vous ?
@codeursenior
7 ай бұрын
Bonjour, ce que je propose dans la vidéo est l'implémentation d'un Value Object du Domain Driven Design (DDD). Ce que vous proposez ne respecte pas ce paradigme précis, mais pourrais avoir un intérêt selon le projet. Par contre, je vous recommande de définir vos propriétés comme statique : class BankNote { static Ten = 10; static Twenty = 20; static Fifty = 50; }
@BastienFacquet
7 ай бұрын
@@codeursenior Effectivement j'ai omis l'implémentation et je suis donc hors contexte. Désolé. Merci pour votre réponse et bonne journée
@codeursenior
7 ай бұрын
@@BastienFacquet Pas de soucis, bon code à vous.
@DD3874
11 ай бұрын
Merci !
@deluis9710
11 ай бұрын
Merci
@SlowedOutOfExistence
11 ай бұрын
D'accord c'est vraiment un problème de junior négatif 2 années d'expérience. N'importe quel dev bien formé sait qu'il doit utiliser Typescript, plutôt que JavaScript avec 4 milles classes qui emulent du type safety. Il y a aussi le paquet npm zod pour créer des types avancés
@wanstalker107
11 ай бұрын
5:48 Pourquoi ne pas avoir utilisé un type somme à la place de number et d’une liste « validAmounts » ? Il y a des cas bizarres au runtime ?
@round-lap
11 ай бұрын
Tout est objet en Javascript je suis confus
@codeursenior
11 ай бұрын
Qu’est ce qui vous semble problématique exactement ?
@vulcanjibe
11 ай бұрын
Euh... Vous me faites peur là qd même. La reflexion objet c est la base du développement, c est pas avec ca que tu deviens dev senior 😂😂😂😂
@codeursenior
11 ай бұрын
Je présente ici le concept de Value Object (refactoring de Martin Flower + Domain Driven Design de Éric Evans). Jamais entendu de la « réflexion objet ».
@vulcanjibe
11 ай бұрын
@@codeurseniorc est la phrase du début qui m a un peu tué : je faisais du dev web donc la Poo on s en fichait un peu 😂😂😂. A part sur des projets récupérés sur du dev d indien débutant (j ai rien contre les indiens mais ils font du sacré code de merde...), j ai jamais eu affaire a du code web sans objet, débutant inclus. Après y a tjs des débutants qui font encore du JavaScript au lieu du typescript, mais en entreprise ça se fait rare pour des questions évidentes de maintenabilité.
@codeursenior
11 ай бұрын
@@vulcanjibe Haha d'accord ! Par contre, étonnez-vous : Il est toujours possible de trouver du code plus "junior" qu'on ne le pense. 👍
@jeankruger9798
11 ай бұрын
Ce qui est top aussi c'est du point de vue de l'evolutivité du code. Dans cet exemple, ça pourrait être de devoir gérer les multi-devises.
@codeursenior
11 ай бұрын
Yep tout à fait 👍 Bon code, Simon.
@is-sam
11 ай бұрын
Putain mec tu te vante d'être sénior et tu ose écrire un if else non nécessaire ? t'a un return dans le if t'a pas besoin du else .. enfin bref, pas convaincu de ton archi farfelue qui ne fait que complexifier le code et augmenter la taille de code et le temps de dev pour pas grand chose au final.
@codeursenior
10 ай бұрын
Archi farfelue 🥲 (je présente ici le Refactoring de Martin Fowler ‘primitive obscession’ et le Value Object du Domain Driven Design d’Eric Evans)
@is-sam
10 ай бұрын
@@codeursenior Si tu bosse pas chez Amazon ou SpaceX pas la peine d'aller aussi loin
@codeursenior
10 ай бұрын
@@is-sam Tout à fait. Vous avez raison.
@camelcase169
11 ай бұрын
Bonjour, merci pour la vidéo, c'est très intéressant. J'aimerais avoir votre avis sur un exemple (dans le contexte d'un objet servant à l'économie d'un jeu). Imaginons que je souhaite représenter un diamant en tant qu'objet : Le diamant est un "object value", avec des propriétés telles que le carat, la couleur et son intensité (pour rester simple). Chacune de ces propriétés est readonly et est définie à la création de l'objet (lorsque le joueur mine un bloc, par exemple). En suivant votre exemple, dans ma classe "diamant", le carat serait un intervalle entre 0.1 et 10 (à titre d'exemple), et la couleur du diamant serait également un "object value" avec comme propriétés la couleur et son intensité. D'ailleurs, si dans un jeu je voulais définir une notion de "poids" pour un personnage, une ressource, etc., je pourrais également concevoir un objet "Poids" qui serait créé dans le but de définir des limites de poids en fonction du contexte. Par exemple : un personnage peut avoir un poids entre 35 et 160 kg, une épée peut avoir un poids entre 800 g et 6 kg (juste pour l'exemple). Merci pour votre retour.
@mohamedr1164
11 ай бұрын
Pourquoi pas ne réserver la méthode equals aux entités et trouver un autre nom pour la méthode de comparaison de valeur
@DavidRENAUD-ss5yj
11 ай бұрын
Merci Simon, toujours intéressantes ces vidéos. Mon avis est qu'il faut trouver un juste milieu entre les primitifs et value object. Sinon ton dev qui a tout recodé un soir aurait peut être pu expliquer ce qu'il n'aimait pas puis déléguer aux jeunes pour les faire progresser, ça c'est du lead ! 😁 👋A très bientôt pour la prochaine vidéo 👍
@tortue34170
Жыл бұрын
Super vidéo ! Merci ! Je découvre la chaîne, mais je vais creuser ! D'ailleurs j'entends "pas la peine de s'abonner" pour la première fois je crois ! Génial haha ! Je m'abonne direct ! 😂
@vincentcottalorda2105
Жыл бұрын
Jl’ai toujours dit ces conneries de string et number selon comme on les tourne… l’important c’est les valeurs !!!
@lucasvencatachellum836
11 ай бұрын
Quand tu mets un type en paramètre, ça s'est a quelque chose de mettre en condition typeof ?
@PW_Thorn
11 ай бұрын
Ca démange de coder une boucle infinie sur un new Banknote. Juste pour le kiff...
@masterchief9148
Жыл бұрын
Donc si j'ai bien saisi ça ferait que pour un email on formaterai tout ça pour que Email corresponde à un format email ?
@erischon8047
Жыл бұрын
Merci pour cette video fort intéressante. Pourrais tu donner le lien pour l’inscription à la newsletter stp, je dois être bigleux mais je ne l’ai pas trouvé 😇, merci.
@boristherin4104
11 ай бұрын
Merci, ca éclaire pourquoi on retourne avec notre copie au travail. On as plus l'habitude d'essuyer un échec sans qu'on explique pourquoi ou sans que l'on ose demander (remise en cause de ses competences).
@vamosplaya2797
Жыл бұрын
Ça serait intéressant de l'inclure dans une playlist "Code réutilisable" (Reuse Code). Et éventuellement pousser la réflexion plus loin notamment sur La définition des formulaires typés selon une classe modèle, où le principe est grosso modo similaire. C'est véritablement ces aspects qui font la différence en entretreprise pouvoir ré écrire du code réutilisable basé sur un type "générique" .
@RogerArbogast
11 ай бұрын
Jolie histoire. Si elle est vraie, elle démontre une vraie intention de ta part de t'améliorer, et ça, c'est le plus important :)
@dev-rachid
10 ай бұрын
merci beaucoup 👍
@codeursenior
10 ай бұрын
Merci à toi.
@rickushner3831
Жыл бұрын
Merci pour la vidéo surtout le conseil qui est celui de pratiquer pendant l'apprentissage. Merci....
@noahsarcana
11 ай бұрын
Le type a peut-être raison par contre son comportement est nul. La moindre des choses c'est de venir voir les dev débutants pour expliquer pourquoi on fait une refacto
@codeursenior
11 ай бұрын
La technique de la gueulante avait marché sur le coup, mais l'ambiance sur le projet ne s'en est jamais remis malheureusement…
@christophedidier6758
11 ай бұрын
Le seul vrai langage c’est l’assembleur! 😊
@codeursenior
11 ай бұрын
Mais oui bien sûr, j'ai oublié de le mentionner dans la vidéo !
@_yukulele
11 ай бұрын
pourquoi ne pas gérer les erreurs directement dans le constructeur ?
@mokalux
Жыл бұрын
merci pour cette excellente vidéo J'aime bien le format, court et va directement à l'essentiel. Vivement la prochaine ;-)
@LeighChr
Жыл бұрын
Merci Simon, tes vidéos sont toujours aussi intéressantes ! :) J'ai une petite question par rapport à la validation du montant des billets : Au lieu de valider la variable amount de type Number dans le constructeur comme tu l'as fait, peut-on simplement créer un type Amount ne pouvant prendre que certains nombres en valeur ou cela ne serait pas suffisant ? Continue comme ça, j'adore ce que tu fais !!
@MrPierreSab
Жыл бұрын
je connais pas le typescript donc je ne sais pas si on peut y creer des "enum"
@vamosplaya2797
Жыл бұрын
J'ai écris 2 réponses à ce sujet avec du code mais KZitem n'a pas l'air de les accepter. Intéresse toi aux types énumérer (Enum), cela permet essentiellement de définir un ensemble de valeurs possible pour une propriété, empêchant ainsi toute autre valeur non répertorier dans ton type énumérer ...
@boristherin4104
11 ай бұрын
@@vamosplaya2797 j'ai remarquer si tu essaies mettre des liens autres que youtube dans tes reponses, le post n'est pas pris en compte sans aucune alertes. C'est navrant ces plateformes de communications 'limités' au 21eme siecle, quand on pense que la majorite de la planete s'exprime en 280 char (twitter), presque ca inquiete. Si seulement on pouvait faire du markdown ...
@mielderuche8027
11 ай бұрын
Je suis du même avis que @virgil5113 autre point, pour valider un mail ou tel une regex ne suffit pas ?
Merci beaucoup pour le tip, c'est vraiment sympa de prendre du temps pour nous expliquer tout ça.
@cours458
11 ай бұрын
dans un jeux video ça fait sens d'avoir des billet de banque car les instance sont litteralement des objets dans le jeux, mais dans un api je vois pas pourquoi, c'etait quoi cette api? c'etait un example just pour example? Tu nous as expliquer comment faire mais pas qu'est ce qu'on y gagne, dans quel cas ça nous sera utile et pourquoi ça pourrais causer des probleme de ne pas le faire.
@codeursenior
11 ай бұрын
Hello, merci pour ton commentaire pertinent. Les Value Objects sont essentiels pour plusieurs raisons : 1/ Encapsulation : Ils garantissent la validité et la cohérence des données tout au long de leur cycle de vie. 2/ Réutilisabilité : Tu peux les utiliser à travers différents contextes sans avoir à dupliquer la logique. 3/ Abstraction : Ils simplifient la complexité en encapsulant la logique métier. Ne pas les utiliser pourrait engendrer des bugs, de la duplication de code et rendre le système moins maintenable. Pense aux Value Objects comme à des fondations solides pour ton architecture. Sans elles, ta maison logicielle pourrait s'effondrer plus facilement.
@brokencydeAwful
11 ай бұрын
Hello, ta vidéo est intéressante et bien faite. Un point je pense qui pourrait être améliorer : De la même manière qu'à la fac, la théorie ne t'a pas du tout parlé, dans cette vidéo c'est la même chose pour l'immutabilité ! Tu dis que si on crée un billet de banque de 10€ on veut qu'il garde cette valeur et qu'il ne soit pas invalide. En effet tu as raison mais, pourquoi ? C'est comme tu dis, un dev junior ne pourrait comprendre ce nouveau concept que s'il répond à une problématique. La première raison d'avoir utilisé massivement ce pattern de value objects était surtout parce que dans les applications multi-threaded (genre...des applis Java :D), il y avait des soucis de concurrence où plusieurs process modifiaient les mêmes objets en mémoire. Et les objets en question avaient parfois des valeurs qui n'avaient aucun sens, et les bugs "cascadaient". Ensuite on s'est aussi rendu compte, et tu le montres dans les points suivants, qu'on pouvait garder toute notion de validation/comparaison de ces objets directement dans leur définition ce qui simplifiait grandement le code (réutilisation + tout est au même endroit).
@zHqqrdz
11 ай бұрын
totalement 👍
@pH7Programming
10 ай бұрын
Très chouette visionage 😎
@SelfTalk0
Жыл бұрын
Merci infiniment 🎉 C'est ouf comment c'est utile ! Et précis !
@jamalimehli1406
Жыл бұрын
Simon le meilleur !!!! Merci pour ces mines d'or !!!
@gilespeche6025
11 ай бұрын
Powerpoint mène le monde à sa perte
@alienduweb
Жыл бұрын
effectivement super conseil et très sécurisant
@jonathanclaerebout3707
Жыл бұрын
Merci Simon. Contenu interessant et explicite 👍
@BelgaWill
11 ай бұрын
Merci pour cette vidéo !
@Yokenshiro11
11 ай бұрын
je comprends tous ce que tu dis mais ça a l'air bcp plus dure a implementer.
@codeursenior
11 ай бұрын
Hello, normalement je donne un exemple concret de code que j’utilise en fin de vidéo. Je pourrait faire une vidéo plus concrète avec un cas d’utilisation réel.
@matthieudantes4129
11 ай бұрын
merci pour la vidéo!
@lucykuminska366
Жыл бұрын
Vidéo très sympa, même si pas facile de comprendre les tenants et aboutissants de la chose quand tu débutes comme moi. J'apprécie beaucoup ton côté très ancré dans le réel (aka code en entreprise). J'apporterai juste un conseil si tu cherches à être encore plus clair pour un public novice (mais ce n'est peut être pas le cas hein), c'est de prendre un chouia de temps pour commenter ligne par ligne ce que tu exposes comme code (que je garde précieusement). Après ça peut se faire dans une autre vidéo, du type : une vidéo "d'appel" de 10 minutes comme là, et une vidéo allongé où tu rendres plus en détail. Au plaisir de regarder les prochaines en tout cas (et merci pour la ressource Refactoring Guru, dur à saisir, mais très éclairante)
@erkenoss7215
11 ай бұрын
Prend le temps de recopier sur un éditeur, puis, si tu ne le comprends toujours pas. Regarde sur internet les réponse que tu pourrais avoir. Si ce n'est toujours pas encore compris, passe par Chat de sorte qu'il te l'explique. Dis lui bien de ne pas te sortir de code. C'est un outil puissant mais attention à ne pas te laisser avoir par la facilité, sinon, tu apprendras jamais rien. Enfin, demande à d'autre personne dans le même cas que toi (si tu en connais)
@Antipyj
Жыл бұрын
Bouerf pour moi c'est au back de faire ça, le mec qui veut mettre un chiffre a virgule il y arrivera avec un peu d'inspection
@codeursenior
11 ай бұрын
Et oui, avec suffisamment "d'inspection", on peut mettre des virgules dans les billets de banque.
@sdmuro
11 ай бұрын
Très sympa, merci
@jfjoubertquebec
11 ай бұрын
Oui, un billet de banque c'est des conditions, des descriptions, des caractéristiques,
@codeursenior
11 ай бұрын
Tout à fait. 👍
@iamghezali
11 ай бұрын
très instructif, merci
@NiOpt
11 ай бұрын
C'est très très bien vulgarisé, j'aime beaucoup bravo
@codeursenior
11 ай бұрын
Au top, merci pour ton retour et bon code à toi ! Simon.
@angeorsolani5504
Жыл бұрын
Très intéressant.
@JeremyGasperowicz
Жыл бұрын
👍
@tamantaman
Жыл бұрын
Merci.
@wagnernicolas1801
Жыл бұрын
On en parle du "Adress" c'était fait exprès ?
@codeursenior
11 ай бұрын
Hello, c'est une typo : Address serait le terme exact.
@rcoolmusic2836
Жыл бұрын
Je fais depuis longtemps, alors je suis déjà Senior !
@manuelminana4826
11 ай бұрын
non, c'est tellement basique ...
@alansmithee722
Жыл бұрын
Très intéressantes ces vidéos axées sur la conception logicielle. Je suis moi-même en charge d'enseigner la POO en lycée, à l'aise avec ses concepts avancées. Et pourtant, je n'aurais eu cette idée de classe Billet. As-tu des ouvrages/sources recommandées pour améliorer cet aspect du codage (si possible python) ? Face aux élèves, je n'aurai jamais de retour de dév senior.
@Brictarus
11 ай бұрын
Ce sont des briques de base de DDD (domain driven design). Il y a pas mal de littérature sur le sujet.
@Brictarus
11 ай бұрын
Certain parle également de type driven development.
@remigaborit2486
11 ай бұрын
Merci pour l'astuce/conseil. Mais on pourrait utiliser des RegEx (dans les objets, plutôt de que des tableaux) ?
@dihcarkouane7020
11 ай бұрын
Ça dépend de ce que tu test. Ici c'est une liste de valeur 5, 10, 20, 50... L'utilisation d'une regex n'a pas d'utilité particulière et le tableau pour une liste est bien plus lisible
@remigaborit2486
11 ай бұрын
@@dihcarkouane7020 En effet, dans ce cas. Mais pour les e-mail, numéro de téléphone...
@cocoludo
11 ай бұрын
Petite question pratique : quelle serait la bonne pratique pour ranger ces classes dans un projet en général. C'est sûrement un question bête, désolé par avance pour cela. J'imagine qu'il y a autant de structure de projet que de framework. Merci encore Simon pour tes vidéo extrêmement intéressantes et didactiques. Elles m'aident beaucoup dans mon apprentissage.
@tropikalGG
11 ай бұрын
Ranger ses classes fait partie de la compréhension de l'architecture et des designs patterns, chaque projet est différent, la demande métier est une partie centrale. Je te conseille de te renseigner sur l'architecture logicielle propre, il y a de très bons livres a ce sujet comme celui de uncle bob (Robert c. Martin), tu seras plus confiant dans ta création de projet
@cocoludo
11 ай бұрын
@@tropikalGG merci pour ton retour
@nuketoto3868
11 ай бұрын
j'évite les string, ça me sert trop les burnes
@codeursenior
11 ай бұрын
Je n’ai jamais entendu cette blague. Intéressant.
@rachidamirat9470
11 ай бұрын
Bravo et merci pour ton travail toujours très pertinent..
@codeursenior
11 ай бұрын
Au top, merci pour retour ! Bon code pour la suite, Simon.
@wpecnik2
11 ай бұрын
Le java ne connait pas les unsigned
@codeursenior
11 ай бұрын
Ainsi soit-il !
@drevuz
11 ай бұрын
C'etait ou cette école ou il ne savent pas enseigner la programmation ?
@webtutorialwithremi1253
11 ай бұрын
Tu penses que c’est du bullshit ?
@codeursenior
11 ай бұрын
Hello, le master en question existe plus. C’était à l’université Pierre Mandes France à Grenoble qui a été fusionné en UGA depuis.
Пікірлер: 190