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.
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.
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.
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.
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à.
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.
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.
@@ghostsngoblins6894 certes mais c'est absolument pas ce qu'il ou elle a dit. Iel dit que la fac permet d'avoir plus de hauteur dans sa réflexion que les enseignements pratique, ce qui est utile pour faire un travail de qualité puisque c'est exactement ce qui est recommandé dans cette vidéo... mais effectivement, sans pratique y'a pas de boulot !
@@webindefr pas sur... Je constate que la hauteur est souvent présente chez des profils engagés, passionnés et motivés, bien souvent sans parcours universitaire traditionnel. À l'inverse, les développeurs plus classiques ont tendance à se reposer sur leurs acquis et à remettre parfois en question leur choix de carrière.
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
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.
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 ! 😂
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.
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 👍
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.
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.
Рік тому
@@DystoKhan Premature optimisation is the root of all evil cependant...
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.
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 😅
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. 👍
Ç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" .
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)
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)
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
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 !!
J'ai écris 2 réponses à ce sujet avec du code mais UA-cam 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 ...
@@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 ...
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.
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.
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).
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.
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.
@@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 ;)
@@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.
@@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.
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é.
Merci pour cette vidéo Simon !!! Et les autres d'ailleurs ! Juste une question peut être un peu bête mais pourquoi tu utilises une classe abstraite sur des projets en production ? Peux tu détailler un peu plus ce choix stp ?
La classe est abstraite car ça n'aurai pas de sens de l'instanciée. On en revient à ce qu'il explique le but de faire une classe permet de typer ta valueObject. Exemple: tu veux conceptualiser une adresse email alors tu crée une classe Email qui hérite de sa classe abstraite. Et donc dans ton code, la ou tu auras besoin d'un email tu typeras la variable avec ta classe Email. Si tu avais directement utilisé la classe ValueObject tu aurais perdu en lisibilité dans un premier temps et puis tu aurais qu'un comportement la ou avec l'héritage tu peux choisir de garder celui de la classe mère ou de l'overrider et de le changer de ce faite ça n'impacte pas les autres classes. Petit bonus : concernant le comportement d'une classe (méthode) je conseillerai d'utiliser la composition plutôt que l'héritage dans le cas ou tu aurais des comportements à cumuler. La ou avec l'héritage ce n'est pas possible d'hériter de plusieurs classes alors que tu peux implémenter plusieurs interfaces à une classe. Voilà j'espère que j'ai pu t'éclairer. Bonne soirée!
Super@@PsyPoulpy , merci beaucoup pour ta réponse qui me parle et donc qui répond parfaitement a ce que je demandais. C'est vrai que la POO je connais mais bon c'est encore vague sur certaines notions ! Et tu as éclairé mes lanternes en te lisant ! Merci à toi pour cette réponse !!
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
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
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.
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.
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.
Ç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
Merci du partage! J'y connais rien en codage, je ne produit pas de code ni amateur, ni pro, c'est UA-cam qui m'a mener à toi, mais j'ai bien compris ce que tu racontes! Et c'est intéressant, même pour les non codeurs. Bonne journée! Stéph.
Hello Stéph, merci pour ton retour incroyable. Je n'avais jamais imaginé que même des non-développeurs pourraient suivre le contenu. Bonne continuation et à bientôt, Simon.
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.
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
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
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
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; }
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.
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.
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.
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).
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é
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
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.
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
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)
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 ?
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.
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.
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é.
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.
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
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.
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...
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 ;)
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.
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
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 ».
@@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é.
Ça c’est un véritable « game changer » 👍 Merci Simon pour tes vidéos toujours ultra pertinentes et efficaces 🙏
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.
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.
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.
MOI je sui un vrai débutant j'ai beaucoup aimé l'explication Merci à toi Champion
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.
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à.
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.
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.
@@ghostsngoblins6894 certes mais c'est absolument pas ce qu'il ou elle a dit. Iel dit que la fac permet d'avoir plus de hauteur dans sa réflexion que les enseignements pratique, ce qui est utile pour faire un travail de qualité puisque c'est exactement ce qui est recommandé dans cette vidéo... mais effectivement, sans pratique y'a pas de boulot !
@@webindefr pas sur... Je constate que la hauteur est souvent présente chez des profils engagés, passionnés et motivés, bien souvent sans parcours universitaire traditionnel. À l'inverse, les développeurs plus classiques ont tendance à se reposer sur leurs acquis et à remettre parfois en question leur choix de carrière.
Merci pour la vidéo surtout le conseil qui est celui de pratiquer pendant l'apprentissage. Merci....
Subtile introduction au DDD par le bounded context 😉 bon boulot !
Merci à vous !
Bon code,
Simon.
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
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.
Merci beaucoup pour le tip, c'est vraiment sympa de prendre du temps pour nous expliquer tout ça.
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 :)
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 ! 😂
Très chouette visionage 😎
C'est très très bien vulgarisé, j'aime beaucoup bravo
Au top, merci pour ton retour et bon code à toi !
Simon.
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.
Simon le meilleur !!!! Merci pour ces mines d'or !!!
Merci infiniment 🎉 C'est ouf comment c'est utile ! Et précis !
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 👍
merci pour cette excellente vidéo J'aime bien le format, court et va directement à l'essentiel. Vivement la prochaine ;-)
Bravo et merci pour ton travail toujours très pertinent..
Au top, merci pour retour !
Bon code pour la suite,
Simon.
Et maintenant tu vas lire "Array of structs vs struct of arrays" et tu sais plus quoi faire 😂
Belle vidéo! :)
Merci Simon. Contenu interessant et explicite 👍
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.
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.
@@DystoKhan Premature optimisation is the root of all evil cependant...
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.
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 😅
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. 👍
Ç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" .
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)
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)
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
très instructif, merci
Vidéo très instructive ❤ merci
Avec plaisir, merci pour votre retour.
Merci pour cette vidéo !
Je fais depuis longtemps, alors je suis déjà Senior !
non, c'est tellement basique ...
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 !!
je connais pas le typescript donc je ne sais pas si on peut y creer des "enum"
J'ai écris 2 réponses à ce sujet avec du code mais UA-cam 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 ...
@@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 ...
Je suis du même avis que @virgil5113 autre point, pour valider un mail ou tel une regex ne suffit pas ?
@virgil5113, écris ceci : type MontantBilletEuro = 1 | 2 | 5 | 10 | 20 | 50 | 100 | 200 | 500
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.
Yep tout à fait 👍
Bon code, Simon.
merci pour la vidéo!
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.
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.
Très intéressant.
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).
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.
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.
@@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 ;)
@@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.
@@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.
Merci !
Très sympa, merci
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é.
merci beaucoup 👍
Merci à toi.
Merci pour cette vidéo Simon !!! Et les autres d'ailleurs ! Juste une question peut être un peu bête mais pourquoi tu utilises une classe abstraite sur des projets en production ? Peux tu détailler un peu plus ce choix stp ?
La classe est abstraite car ça n'aurai pas de sens de l'instanciée. On en revient à ce qu'il explique le but de faire une classe permet de typer ta valueObject. Exemple: tu veux conceptualiser une adresse email alors tu crée une classe Email qui hérite de sa classe abstraite. Et donc dans ton code, la ou tu auras besoin d'un email tu typeras la variable avec ta classe Email. Si tu avais directement utilisé la classe ValueObject tu aurais perdu en lisibilité dans un premier temps et puis tu aurais qu'un comportement la ou avec l'héritage tu peux choisir de garder celui de la classe mère ou de l'overrider et de le changer de ce faite ça n'impacte pas les autres classes. Petit bonus : concernant le comportement d'une classe (méthode) je conseillerai d'utiliser la composition plutôt que l'héritage dans le cas ou tu aurais des comportements à cumuler. La ou avec l'héritage ce n'est pas possible d'hériter de plusieurs classes alors que tu peux implémenter plusieurs interfaces à une classe. Voilà j'espère que j'ai pu t'éclairer. Bonne soirée!
Super@@PsyPoulpy , merci beaucoup pour ta réponse qui me parle et donc qui répond parfaitement a ce que je demandais. C'est vrai que la POO je connais mais bon c'est encore vague sur certaines notions ! Et tu as éclairé mes lanternes en te lisant ! Merci à toi pour cette réponse !!
@@alexylepretre9296 Pas de souci c'était avec plaisir !
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
Merci
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
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.
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.
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.
Ce sont des briques de base de DDD (domain driven design). Il y a pas mal de littérature sur le sujet.
Certain parle également de type driven development.
Merci pour l'astuce/conseil. Mais on pourrait utiliser des RegEx (dans les objets, plutôt de que des tableaux) ?
Ç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
@@dihcarkouane7020 En effet, dans ce cas. Mais pour les e-mail, numéro de téléphone...
Merci du partage! J'y connais rien en codage, je ne produit pas de code ni amateur, ni pro, c'est UA-cam qui m'a mener à toi, mais j'ai bien compris ce que tu racontes! Et c'est intéressant, même pour les non codeurs. Bonne journée! Stéph.
Hello Stéph, merci pour ton retour incroyable.
Je n'avais jamais imaginé que même des non-développeurs pourraient suivre le contenu.
Bonne continuation et à bientôt,
Simon.
@@codeursenior C'est la magie de youtube. Moi je regarde des vidéos d'un tpe qui soigne les sabots des vaches et ça me passionne lol
@@noahsarcana Ah ça par contre, c'est normal, le sujet est passionnant !
Merci.
Merci ! 👍
Avec plaisir 👍
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.
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
@@tropikalGG merci pour ton retour
Et oui ça s'appelle encapsulation et c'est un pilier de l'orienté objet (l'autre étant l'héritage de type).
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
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
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 ?
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;
}
@@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
@@BastienFacquet Pas de soucis, bon code à vous.
Quand tu mets un type en paramètre, ça s'est a quelque chose de mettre en condition typeof ?
Pour l'exemple du billet de banque c'est pas plus simple de faire une enum avec les valeurs 5, 10, 20 etc ?
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.
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.
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.
Donc si j'ai bien saisi ça ferait que pour un email on formaterai tout ça pour que Email corresponde à un format email ?
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).
totalement 👍
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 ?
Un peu dommage de ne pas parler des enum avec qui permettent d'avoir un set fermé de valeur
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é
@@KokahZ777 Et rien n'empêche de cumuler les deux, je parlais des enums vis-à-vis des valeurs hardcoded
Le seul vrai langage c’est l’assembleur! 😊
Mais oui bien sûr, j'ai oublié de le mentionner dans la vidéo !
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
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.
"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.
constant?
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
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)
C'est une bonne idée de se lancer dans le DEV WEB en 2023 ? Ou c'est trop tard ?
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 ?
L'inconvénient c'est quand même la place que ça prend dans la mémoire par rapport à une valeur primitive.
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.
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
Un enum de BankNote suffit.. je dis ca, je dis rien ^^
pourquoi ne pas gérer les erreurs directement dans le constructeur ?
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.
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é.
Les exams de code sur papier c’est ce qui m’a fait quitter la fac
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
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.
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.
👍
Jl’ai toujours dit ces conneries de string et number selon comme on les tourne… l’important c’est les valeurs !!!
donc car ca va prendre plus de ram et de cpu..
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
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.
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...
Oui, un billet de banque c'est des conditions, des descriptions, des caractéristiques,
Tout à fait. 👍
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
Et oui, avec suffisamment "d'inspection", on peut mettre des virgules dans les billets de banque.
Ça devrait être considéré comme la base... Ça me fait croire que le niveau est vraiment bas en France 😬
Et pour compter le nombre d'objets, on va utiliser une variable de type...
1:00
Javascript: *est un langage orienté objet*
Simon: En javascript l'orienté objet on s'en fiche un ptit peu
what- 🤣🤣
Pour ma défense : JavaScript est un langage orienté objet… basé sur les prototype… que personne ne maîtrise vraiment !
Tout est objet en Javascript je suis confus
Qu’est ce qui vous semble problématique exactement ?
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 ;)
Ca démange de coder une boucle infinie sur un new Banknote. Juste pour le kiff...
je comprends tous ce que tu dis mais ça a l'air bcp plus dure a implementer.
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.
Le java ne connait pas les unsigned
Ainsi soit-il !
On en parle du "Adress" c'était fait exprès ?
Hello, c'est une typo : Address serait le terme exact.
C'etait ou cette école ou il ne savent pas enseigner la programmation ?
Tu penses que c’est du bullshit ?
Hello, le master en question existe plus. C’était à l’université Pierre Mandes France à Grenoble qui a été fusionné en UGA depuis.
j'évite les string, ça me sert trop les burnes
Je n’ai jamais entendu cette blague. Intéressant.
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
La technique de la gueulante avait marché sur le coup, mais l'ambiance sur le projet ne s'en est jamais remis malheureusement…
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 😂😂😂😂
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 ».
@@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é.
@@vulcanjibe Haha d'accord ! Par contre, étonnez-vous : Il est toujours possible de trouver du code plus "junior" qu'on ne le pense. 👍
Aucune valeur ajoutée dans votre discours bla bla bla