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.

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à.

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 à vous ! Bon code, Simon.

Au top, merci pour ton retour et bon code à toi ! Simon.

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.

Au top, merci pour retour ! Bon code pour la suite, Simon.

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. 👍

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)

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.

Avec plaisir, merci pour votre retour.

Merci à toi.

Yep tout à fait 👍 Bon code, Simon.

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.

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

non, c'est tellement basique ...

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 KZfaq 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

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)

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.

Avec plaisir 👍

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 !

totalement 👍

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

@@user-hn9fb1vo2s Pas de soucis, bon code à vous.

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

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é.

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.

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, 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.

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 !

constant?

Ç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...

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 ?

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...

Mais oui bien sûr, j'ai oublié de le mentionner dans la vidéo !

Et oui, avec suffisamment "d'inspection", on peut mettre des virgules dans les billets de banque.

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

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.

Qu’est ce qui vous semble problématique exactement ?

Tout à fait. 👍

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.

Hello, c'est une typo : Address serait le terme exact.

Ainsi soit-il !

Pour ma défense : JavaScript est un langage orienté objet… basé sur les prototype… que personne ne maîtrise vraiment !

Je n’ai jamais entendu cette blague. Intéressant.

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.

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. 👍