Un petit retour pour remercier Simon pour son travail. J'ai commencé Angular avec ton livre (génial), j'ai pris des stagiaires en les poussant sur Angular grâce à ton cours "Apprendre Angular", avant d'entrer en stage chez moi et ils sont maintenant en CDI de dev frontend Angular dans d'autres entreprises. J'ai aussi suivi le cours de Simon "Maîtriser Angular en Entreprise" et c'est vraiment le top! Agréable à lire et le fait de comprendre chaque ligne de code sur un vrai projet a l'architecture solide est rassurant et très plaisant (j'aime encore plus Angular). Très complet ! Un grand merci de nous donner cette vision professionnelle du dev pour des étudiants qui n'ont pas forcement possibilité de faire des stages ou autre dans de vrais projet Angular. Cela permet de moins redouter l'entrée dans la vie pro. N'hésitez surtout pas !
Merci pour ton retour Maxime, ça me touche beaucoup. Je suis très fier d'avoir pu t'aider même d'un millimètre dans ton parcours. Excellente continuation à toi !
Vous avez vraiment un don pour réussir à rendre ces concepts complexes en quelque chose d'accessible et surtout de le faire avec une approche très concrète
Merci Kevin, je n'aurais pas pu lire de meilleurs compliments ! Mon objectif est de rendre toutes ces techniques accessibles à tout le monde. Bon développement à vous, Simon.
En tant que jeune apprenant suite à une reconversion, ta vidéo est incroyable ! Les explications et le codes sont très faciles à comprendre, tu es super pédagogue. Merci beaucoup
Comme toi à l'époque je ne savais pas trop comment les utiliser. Mais après être tombé sur explication plutôt claire, pour un problème que j'avais rencontré, j'ai trouvé ça génial et passionnant. Donc 100% ok pour que tu nous expliques d'autres design Patterns !
C'est un design pattern qu'il est bon de savoir, mais en vrai, en JS/TS, un simple objet options dans le constructor avec des valeurs par défaut (et des union type pour les propriétés "magic string") ça reste quand même plus confort (et beaucoup plus familier). Ca permet aussi de plus facilement passer les options d'objet en objet si besoin (pas forcément un truc que je recommande, mais imaginons que, par example, tu aies un composant qui va afficher, entre autre, une snackbar, et que cette snackbar doit être configurable de l'extérieur)
Hello, discussion intéressante ! Effectivement, c'est l'approche "JS hacker" par défaut. Mais par rapport à la problématique de la vidéo, comment fais-tu pour encapsuler des configurations ? (Toutes les snackbars d'informations sont bleues, durent 3000 millisecondes, et ne peuvent pas être fermées). Au plaisir d'échanger, Simon.
@@codeursenior Merci de la réponse ! Je ne dirais pas forcément que c'est une approche "JS hacker", mais une plus une approche qui respecte l'esprit des design pattern tout en prenant en considération les spécificités du language (ici Typescript avec le destructuring + default parameters). Pour ce qui est de l'encapsulation, des paramètres valeurs par défaut dans ton objet d'options permettent de rester plus flexible et future proof : si tu ne précises pas , tu as les valeurs par défaut pour la couleur, le timeout etc, mais tu peux au besoin, un jour, overrider ça (je suppose que l'on connait bien tous les deux les demandes métier sorties du popotin qui te tombent sur le coin de la figure du jour au lendemain). Si vraiment il y a besoin de dire "non, zut, les snackbar durent 3 secondes, point", tu as toujours plusieurs façons de faire, définir tes proçpriétés privées dans le constructeur (mouais), utiliser des valeurs hard codées vu que de toutes façons ce n'est pas configurable (mouais aussi mais dans le fond...), ou alors wrapper ça dans des factory qui vont envoyer les bons params "forcés", ce qui est une bonne approche car, encore une fois, ça te laisse une snackbar de plus bas niveau entièrement paramétrable si besoin.
@@darialyphia Hello, merci pour ton retour. J'ai une tâche de refactoring qui arrive bientôt donc je regarderai si je peux "casser" l'héritage de classe imposé par le Design Pattern Builder pour créer quelques choses de souple. Mais j'ai encore un peu de mal à voir comment tu encapsule 4 configurations différentes juste avec des options par défaut dans le constructeur. Comment créer des relations entre les propriétés à l'initialisation de la snackbar ? (Si type=information, alors duration=3000 & icon=clochue, et propriétés non modifiable de dehors). Quoi qu'il en soit j'irai tester ça sur le terrain, merci pour ton retour complet. 🙂 Bon développement, Simon.
@@codeursenior pour cette problématique j'aurais utilisé des variants nommés (success, alert, error...), à partir de là tu peux tout conditionner, tu fais du pattern matching au besoin et tu mets juste une valeur par défaut dans ton constructor sur ce qui est commun
@@codeursenior T'es pas obligé d'utiliser des types primitifs dans ton ctor. Si le paramètre "message" à lui seul fait du sens pour ce cas d'utilisation, tant mieux. Mais si le paramètre "duration" ou "icon" ou un autre n'a pas de sens à lui seul, et que tu devras gérer des cas pénibles avec des relations entre les paramètres qui vont conduire à du bordel sans nom et un immense plat de spaghetti, alors, peut-être que passer un type spécialisé en paramètre aura plus de sens que de simplement utiliser des types primitifs. A noter aussi que dans un cas comme celui que je décris, on s'approcherait un peu du concept d'injection de dépendance.
Merci pour ta chaine TH-cam, car tu fais évolué beaucoup EN FRANCE L INFORMATIQUE contre le Monde ANGLOPHONNE qui est Puissant dans le ce domaine!! Continue ta chaine youtube MERCI
Hello, merci beaucoup pour ton message, ça me va droit au cœur. Je vais tout faire pour honorer la mission 👍Et il n'y a pas qu'en informatique que le monde anglophone est (trop ?) puissant...
Pour apprendre et surtout comprendre les Design Pattern, rien de mieux que le livre Design Pattern Tête La Première, ce bouquin est magique. Et contrairement à ce que tu dis, je conseille de le lire avant d'avoir rencontré les problèmes, car il expose justement très bien les problèmes et le chemin de réflexion qui mène jusqu'au Design Pattern étudié. 😊
vidéo qui tombe a point nommée! je viens d'être embauché en Junior. Lors de l'entretien, j'ai été coincé sur la question des design pattern. J'y vois déjà plus clair. merci !
Incroyable... Je te remercie j'étais mais alors là EXACTEMENT dans la situation que tu décrivais en début de vidéo, j'avais beau lire des articles, ou voir des documents sur les designs pattern, je n'arrivais absolument pas à avoir la compréhension de l'utilisation d'un design pattern, et pour le design pattern builder tout autant, et là j'ai l'impression que tu m'as ouvert les yeux... Même si je expérimente pas en JavaScript, grâce à toi je pense pouvoir l'utiliser dans un cas concret en java et pour ça merci milles fois !
Pour le coup l'observer ou poids mouche sont aussi des concepts que je trouve intéressant par principe mais le fonctionnement me perd vraiment, je ne sais pas si tu as déjà fait d'autres explications de design pattern, mais celui là est une grande réussite de mon côté !
Merci pour ton retour, le but de la vidéo était justement ne plus être fâché avec les Design Patterns ! 💪 Objectif atteint donc. ^^ Bon développement à toi, Simon.
"Prendre le temps de penser". Je n'aurais pas dit mieux, c'est clairement ce qui permet d'aller beaucoup plus vite à moyen et long terme. 👍 Bon développement à toi, Simon.
Merci tu m'a fait comprendre des choses intéressantes sur ce design pattern ! Des vidéos sur les designs patterns c'est excellent. Si tu peux faire une petite série de vidéos sur ce sujet ce serai vraiment bien. C'est réellement une forte valeur ajouté de savoir utiliser et surtout QUAND utiliser un design pattern. Tes explications sont au top, j'ai 5 ans d'expérience dans le code donc j'ai un peu ( je dis bien un peu) d'expérience et vraiment j'ai trouvé cette vidéo Super explicite et Utile. D'autres stp !
Hello, merci pour ton message ! Je te confirme que je planche une petite série sur les Design Patterns, orienté 100% vrai-vie / développeur frontend. 👍 Bon développement, Simon.
Le même réponse, malgré 10 ans d'expériences je n'ai jamais coder réellement comme ca mais ca donne envie. Je suis pour une série sur les design pattern aussi :)
Merci à toi Samir ! 👍 Je me demandais justement si tout allais être assez clair, étant donné que les Design Patterns sont plutôt "abstraits" en soi. Bon développement à toi ! Simon.
Waouh c'est tout simplement magnifique ! Je suis tombé amoureux des design patterns. Je ne comprenais pas trop leur nécessité mais maintenant, grâce à vous ce n'est plus le cas. Le code qui marche ne me suffit plus et je veux en apprendre plus. Svp pourriez vous présenter d'autres design ? Sur TH-cam ce n'est pas bien expliqué.
Bonjour, bienvenu au club des amoureux du bon code ! Si le code qui marche ne vous suffit plus, je veux que vous vous sentiez au BON ENDROIT sur cette chaîne. 💪 Vous trouverez la playlist de tous les design patterns expliqué sur la chaîne sur ce lien : th-cam.com/play/PLhVogk7htzNhf1sPcvTQzHV_Jv6-LOmLi.html La playlist est en cours de construction, mais certains design pattern sont déjà disponible. Bon code à vous !
Salut Simon merci pour tes vidéos, elles sont très pertinentes. Je suis aussi formateur JavaScript mais j'ai 23ans, pas encore formateur Angular mais j’arrive je te rattrape ^^
@@burdygoureige6619 Oui carrément c'est une excellente idée. Je vais plutôt montrer le côté REEL de tout ça. Par exemple, je n'implémente jamais le Pattern Observer en Angular quand j'en ai besoin... puisque je peux simplement créer un Observable/subscribe(). Bref, vais présenter ça sous un angle de la vraie vie, côté frontend. 👍 À +, Simon.
Tes vidéos sont géniales. Je suis un dev react et je dois rapidement me former sur angular, j’intègre une entreprise dans deux semaines. Merci pour toutes tes vidéos. C’est clair, précis et ça permet de monter en compétence rapidement. Tu aurais un lien sur le quel je peux trouver les principaux design patterns en angular ? Merci 🤩
Merci beaucoup ! Je passe beaucoup de temps sur Symfony ces derniers temps et j'ai toujours eu du mal à comprendre l'intérêt de tout ces "Builders" mais ca devient de suite plus clair et je vois de quelle manière je pourrais implémenter ça dans mon propre code pour le rendre plus simple à utiliser. Encore merci :) +1 like, +1 abonnement, + petit commentaire pour le référencement ;)
Hello Simon, C'est un concept dont j'ai beaucoup entendu parlé mais qui est toujours resté flou. Grâce à ta vidéo, j'ai compris l'utilité et la manière de le mettre en place en - de 5min. Merci :). Perso je suis preneur des autres explications sur les design pattern que tu utilises.
Merci pour ton retour, j'ai réussi ma mission avec cette vidéo ! 🔥 Je me note de faire une série de 23 vidéos sur les Design Patterns (il y en a 23 😉). Bon développement, Simon.
Le code que tu affiche à 8:28, on vois que ta fait du copier/coller et que ta pas finis de renommer les variables car ta 2 fonctions qui sont incorrect ^^' (setSticky & setDuration).
Super vidéo, (je suis étudiant) j'ai toujours du mal à utiliser les design pattern et je me souviendrai de cette vidéo le moment voulu. Honnêtement je galère avec tous les design pattern mais les pires pour moi sont les abstact factory et les singletons donc si tu pouvais faire une vidéo dessus, ce serait top !
Merci pour la qualité de contenu tes vidéos Impressionnant Nous sommes sur les épaules d'un géant Cela offre un regard une respiration une vision plus grande que notre imagination
Salut Michel, Malheureusement, je ne pense pas que ce soit intéressant ici. Cela créerait un anti-focus pour tout le monde, d'un cas d'utilisation de Snackbar dans le DOM. L'objectif ici est 100% d'illustrer le Design Pattern Builder. En espérant que tu comprennes la démarche ! Bon développement, Simon.
Bonjour Simon, j'aime bcp ces petites séries de vidéos courtes sur une notion spécifique en particulier. Dans le même format, un design pattern que j'aimerais bien voir c'est l'injection de dépendance. Ce serait bien d'avoir ton retour sur l'état de l'art de ce design pattern super important et qui aide beaucoup pour les tests. Super vidéo en tout cas👌
Très bonne idée ! Eh bien, je me note votre idée et je retourne plancher sur une petite série de vidéos sur les Design Patterns. 👍 Bon développement, Simon.
Hello Simon, j'ai essayé d'accéder à votre cours, Devenir fullstack javascript mais le lien ne fonctionne pas. Est-ce que le cours n'est plus disponible ?
Hello Laurent, de temps en temps je "ferme" le programme durant 1 mois lorsqu'on est complet. Pour le mois d'aout, le programme est ouvert actuellement. Bon développement à vous ! Simon.
Salut ce que tu appelle snack bar c'est une modal? Ou c'est pas vraiment la même chose ? Je suis sur ce sujet en ce moment, je dois créer une modal qui affiche du contenu dynamique via une api, et ça me rend un peu dingue 😊
Merci pour tes explications. Programmant principalement en c++, je vois l'analogie de ces builders avec les fonctions membres static qui retourne une instance de la classe (ces fonctions ne dépendent d'aucune instance et sont appelées via "NomDeClasse::NomDeFonction(arguments)")
Salut, oui les prochaines vidéos sur les Design Patterns seront en TypeScript ! (comme celle-ci d'ailleurs, tu as l'extrait de code dans la description de la vidéo 👍)
bonjour simon, j'appreci beaucoup tes videos, juste une remarque sur la solution builder que tu as expisé, ca casse le principe OCP, un bon polymorphisme avec le pattern Stategy t'aurais donné un meilleurs resultat
Hello Amine, merci pour ton retour. Oui c’est une piste intéressante, surtout que ça me permet de passer par la composition plutôt que l’héritage. La problématique que j’avais m’a poussé à partir sur le builder, car je dois créer un objet de configuration à passer une librairie. Je ne coder qu’un wrapper. Au plaisir d’échanger, Simon.
Salut Mohamed, je citerai l'adage classique : "Si vous ne savez pas si vous avez besoin de Redux, c'est probablement que vous n'en avez pas besoin". Est-ce que ça t'éclaire ou pas du tout ? 🙃
Salut Simon, je suis nouveau sur la chaîne, j'aurais une question pour toi, ça serait pour savoir si, dans le monde du travail, les développeurs commences directement à faire du code propre ou bien à faire du code qui fonctionne ? Sinon, super vidéo, j'ai appris un truc très intéressant. Merci.
Hello Damien, quel que soit le niveau d'un développeur, je pense que le code que l'on produit passe toujours par ces étapes : Make it work > Make it right > Make it fast. C'est plus une trajectoire à viser qu'une réponse OUI/NON à un instant t. Voilà ! :) Bon développement, Simon.
Bonjour @Makes, oui tout à fait. Précision que j'aurais peut-être dû apporter. En fait, c'est SnackbarBuilder qui va gérér la création des Snackbars. Mais Snackbar est une classe également, qu'on pourra rendre protégée et accessible au Builder. Ainsi, on est obligé de créer des instances de snackbars en passant par le builder comme on le voulait. 👍
@@polipos8341 Oui, c'est une possibilité, mais je pense que tu perdras le typage TypeScript sur l'élément Snackbar retourné. Peut-être ajouté "as Snackbar" et créer une interface snackbar.model.ts ?
😂 Haha, c'est la première étape pour apprendre les Design Patterns... Se rendre compte qu'on aurait pu en avoir besoin ! Bon courage pour la Fac, je suis passé par là... Simon.
Salut Yamine, Pure erreur d'inatention au milieu du montage/tournage. C'est bien un setter "classique" pour ce design pattern: ```` private setDuration(duration: number) { this.duration = duration; return this. } ``` Je viens de mettre à jour le code dans la description de la vidéo. Merci !
je n'arrive pas a bien saisir sur le fond la différence avec une factory, sur la forme ca permet l'autocompletion je suppose mais sur le fond, on a les elements en commun au niveau de la classe abstraite et les specificites au niveau de chaque classe d'heritage,
Bonjour, le Factory pattern crée des objets en fonction d'un type spécifié sans exposer la logique de création, tandis que le Builder pattern construit un objet étape par étape, permettant de créer des variantes complexes de cet objet. C'est l'étape d'abstraction supplémentaire, quand la compléxité de création devient trop lourde à exposer.
Pourrais tu nous faire une introduction au logging (journal d'erreur) ? comment l'integrer ? que faut-il y ecrire ou non ? comment regler different niveau si necessaire et sur quels critères ? C'est rarement abordé mais ça me parrait essentiel pour trouver et resoudre des problemes qui eux n'apparaissent pas dans les compilateurs.
Je pense qu'il y a un copier/coller malencontreux sur setDuration (8min28. Merci pour la vidéo, je vais essayer de passer un peu de temps sur ces design pattern avec lesquels je ne suis pas très familier
Salut Jean-Bernard, effectivement pour le setDuration, c'est bien `this.duration = duration`. Bien vu ! 😉 Bon développement à toi, j'espère que tu auras l'occasion d'implémenter quelques Design Patterns sur du code récurrent !
Merci bien. J'ai toujours du mal à me manger du code qui réponds à des besoins que je n'ai pas encore eu, et j'ai souvent besoin d'un "historique" ("on fait ça parce que d'abord on a fait comme ça et ça marchait, mais ensuite on a voulu étendre à quelque chose de + général/durable/facile à entretenir et du coup on fait ceci ou cela plutôt maintenant"). J’apprécie donc particulièrement quand on me "dénoue" un truc en lui rendant du sens. Tellement + facile et + excitant d'avancer quand on comprend le sens , le pourquoi des choses... 👍
Merci pour votre message, c'est exactement le type de pédagogie que j'essaye de mettre en avant. Se mettre d'accord sur le problème avant la solution ! 👍
Bonjour Simon, dsl de passer par là mais je sais pas si tu captes encore les messages sur library... je suis devenu un de tes clients mais j'ai eu un petit problème. Merci de ton retour.
Bonjour Simon content de pouvoir te retrouver. J'ai une petite question stp: --> Aurais tu une référence de site pour creuser le sujet ? Avec une liste de design pattern les plus couramment utilisés. J'espère que la question n'a pas été déjà posée. Je t'avoue que je n'ai pas eu le courage de lire tous les commentaires. Je suis bien sûr entrain de chercher mais j'aimerai avoir ton avis stp. J'ai vu ce "disign patern" dans une librairie que j'utilise pour filtrer un mot de passe. J'ai trouvé ça tellement beau et efficace et je me demandais justement comment cela fonctionnais. --> Merci donc pour les explications !!!
Salut Nicolas, ça fait plaisir d'échanger à nouveau. J'espère que tu vas bien ! 😉 La référence que j'utilise pour les design patterns est le site REFACTORING GURU : refactoring.guru/fr/design-patterns. Tu trouveras les 23 designs patterns référencés par le Gang Of Four (1994) avec des explications sympas. Bon développement et à bientôt, Simon.
Merci beaucoup pour l'info, oui ca serait cool de mieux expliquer ce concept de design pattern... J'attends d'autres videos et je vais voir qlq tutos sur ca également. Merci beaucoup
Merci, quelle est le pattern pour les méthodes avec beaucoup trop d'arguments, certains inutiles parfois et qui est vilain à lire. J'ai pensé au pattern command mais je suis pas sûre .
Bonjour, c'est un peu plus subtil que ça. Pas sûr qu'il y est une recette côté Design Pattern sur les méthodes avec trop d'arguments. Peut-être regardé du côté Clean Code/Refactoring pour ce genre de soucis. Plus de 1 ou 2 arguments indique généralement un problème de conception. Bon développement, Simon.
Bon exemple de mise en pratique du pattern. As-tu une idée de comment simplifier la pile de "if not null" à l'affichage de la Snackbar? Peut-être en appliquant des Decorators, ce n'est pas "simple" mais ça permet de ne pas risquer de tout casser si l'on doit changer la manière d'afficher une seule des propriétés de la snackbar. Sinon tu pourrais également démontrer le fonctionnement de Bridge pour afficher les différentes notifications mais dans différents contextes (desktop/mobile, ou visitor / admin par exemple). Ce serait également intéressant que tu montres la correspondance du code avec le diagramme UML si cela ne te saoûle pas trop. En fait ces diagrammes sont plus simples que l'on ne le pense , une fois que l'on a compris leur équivalent en code.
Salut Sylvain, Effectivement, j'ai prévu de faire plusieurs vidéos pour présenter les 23 design patterns référencés par le Gang Of Four dans un contexte Frontend/JavaScript. Je manque un peu de temps en ce moment mais c'est bien sur ma todo-list de vidéos. ;) Côté diagramme je vais réfléchir, malheureusement cela ne m'as jamais aidé à réellement comprendre l'intérêt des design patterns par rapport à du code "en action". A voir si je change d'avis ! Bon développement, Simon.
@@codeursenior C'est une bonne idée de série, qui peut représenter énormément de travail pour couvrir les 23! Je pense que les plus intéressants ce sont les patterns que tu as personnellement utilisé en mission et ou en poste. Après l'UML c'est au goût de chacun, personnellement, cela m'aide de réfléchir en abstraction plutôt que directement en coe, mais chacun sa méthode.
Bonjour, j'ai essayé de mettre le code source dans la vidéo à 11:21. Est-ce que c'est lisible ou pas du tout ? Sinon je peux regarder pour l'ajouter en description. Ce serait peut-être une meilleure solution.
@@nuketoto3868 Re, effectivement ce n'est pas la joie ! Je viens d'ajouter le code du Design Pattern Builder à copier-coller en description de la vidéo 👆 Est-ce que tu as pu le récupérer ? Je pense que cela devrais servir à d'autres développeurs également !
J'ai un probleme justement et je me demande si ya un patern pour ca... Exemple on demande a une fonction de nous donner la personne Patrick donc on fait un espece de getPersonne ( aName : string ) : TPersonne; ca retourne une personne mais la on doit prendre en charge le fait que la fonction a instancier la personne mais c'est nous qui doit le detruire... Parcontre peut etre quon veux pas le detruire car cette personne la doit etre utiliser un peux partout dand notre code... Bref je me demande si je dois garder en note tout les personne cree, exemple dans un tableau de la class personne qui delete tout les personne a la fermeture du programme ... Bref personne c'est un objet simple mais j'ai des objet des fois comme ca qui doit etre refiller a plusieur autre objet qui me demande cette objet ... Mon probleme : c'est objet la qui me demande ma personne pense quil vont devoir le detruire eu aussi. Si il le detruit moi je tombe sur un null object error lollll
Hello Patrick, je vais vous donner mon point de vue à partir de ce que j'ai compris. Premièrement, les Design Patterns ne sont pas des recettes de cuisines. Parfois, on peut "ne pas avoir suffisamment le problème" pour justifier de mettre en place un design pattern. Deuxièmement, j'ai l'impression que vous avez un problème de state management classique : est-ce que j'ai déjà récupéré cette donnée ? est-ce que je veux une version à jour ou le résultat de la dernière requête ? Comment prévenir les autres éléments du programme que l'état a changé dans l'application ? Je vous recommande de regarder du côté des principes Redux et Flux. Bon développement ! Simon.
@@codeursenior Redux et Flux je connais pas.. merci je vais etudier ca un peux. C'est bien d'avoir des nouveau chemin a etudier, qui sais peut etre ma solution vas me venire... Je pense a une variable owner qui dit qui a le droit de detruire...
Salut, -tu devrais éditer cette coquille du code de la description : "setSticky(sticky: string)" -> "setSticky(sticky: boolean)". -ne manquerait-il pas les attibuts au début de la class, par exemple : class SnackbarBuilder { private message: string; private title: string; private sticky: boolean; etc ? -je ne comprends pas : Il existe toujours une class Snackbar publique : "class Snackbar { constructor( private message: string, private title: string, private sticky: boolean, private type: string, private icon: string, private canClose: boolean, private duration: number, ) {} }" puisque la méthode "private build() {return new Snackbar..." en a besoin, non ? Du coup l'utilisateur peut toujours l'utiliser à la place du SnackbarBuilder pour construire des snackbars farfelues, ou quelque chose m'échape ?
Pour le premier point, vous avez raison, mais malheureusement malheureusement je ne peux pas modifier les vidéos TH-cam. Concernant le deuxième point, il s’agit d’une astuce de syntaxe, de type script qui permet d’éviter cette redondance. Concernant le troisième point, il est effectivement possible de créer une snack-bar « libre » en sortant du contexte du Snackbar Builder. Selon le niveau d’abstraction dont vous aurez besoin, sur un gros projet, cette façon de faire pourrait être revue. Bon code !
Sujet très intéressant, même pour quelqu'un qui fait pas d'angular Dans ton cas, ça suffit pas de passer tes props dans un objet et de juste mettre des valeurs par défaut ? Ca donnerait une utilisation genre new Snackbar({title: "foo", message: "foo"}), constructor({title = null, message = null, canClose = false, ...}: { title?: string | null...) Je délire peut être complètement je fais que du react
Je me souviens Dans mon apprentissage ING informatique, Je me souviens Des set et get voila de l'utilité montrer dans votre formation. Parfois Les techniques dev pro permet de devlopper le plus simple,mais l'apprentissage de ces techniques demande de la patience.
Comme dit dans la vidéo le niveau de précision est en fait que la lecture du code devient plus agréable et compréhensible par n’importe quel autre dev.
Bravo pour cette vidéo, t'explique clairement et calmement. On voit ta passion pour le code ca fait plaisir 😜. Je comprends l'intérêt de ce builder mais, de mon point de vue ce qui m'embête c'est cette duplication de code sur les BuildInfo() etc... Potentiellement t'as des devs qui vont suivre cette exemple et mettre une 50ène buildMachin() et si un jour il y a besoin de modifier un comportement pour chaque fonction ça peut devenir l'enfer
Hello JohnV, Merci pour ton retour constructif, voici mes réponses point par point : - Au niveau des méthodes de builds, je ne pense pas qu'il y ait de duplication de code. Au contraire, chaque build possible exprime à la ligne près la configuration à encapsuler. - Aussi, si chaque build exprime une configuration spécifique, normalement, il faudra modifier uniquement cette méthode de build en cas de changement. (Principe Open/Closed de SOLID). - Si jamais le business décide de changer les 4 configurations de build, et bien là, c'est notre boulot d'adapter les 4 méthodes. On n'aura pas le choix. 😇 Qu'en penses-tu ? Au plaisir d'échanger, Simon.
Les explications sont limpides, peut être un peu abruptes pour des juniors, mais avec un peu de notions ça glisse super bien. Étonnant que tu n’aies pas plus d’abonnés 🤔
Bien vu. Je ne fais pas de web mais cette problématique est universelle. Intuitivement je préfère toujours avoir un constructeur non tyrannique, mais tu apportes ici du sens. Notamment sur la consistance/cohérence.
je prefere les constructeurs avec un hash qui donne que les options necessaires, et le constructeur gere les valeur par defaut, ça evite davoir des setter inutile qui traine dans le code de la class et dans l'utilisation, je trouve pas ça tres propre. Le seul probleme de la version "pas senior" c'est qu'en gros on ne sait pas quel param correspond à quoi et qu'on est obligé de passer tous les param, ce qui est idiot
Ah les livres... le moyen de progresser le plus sous-côté ! Bravo à vous donc ! (La série de livres de cet éditeur a une excellente réputation, votre commentaire vient le confirmer une fois de plus !)
Dans toutes les boites que j ai faite on utilisait très rarement ce design pattern. Par contre factory constructor avec un defaut constructor private ça c'est très souvent
Salut, Ce design pattern que tu expliques me fait simplement penser à la POO avec héritage... Les propriétés communes dans la class mère Les propriétés spécifiques dans une class dérivée Intérêt majeur : l'assistance de l'IDE Un objet de la class dérivée aura accès uniquement aux propriétés et méthodes de son type (class dérivée) L'autocomplétion ne proposera que les propriétés et méthodes de son type (class dérivée) contrairement au design pattern builder Alors qu'avec le design pattern builder l'autocomplétion propose des propriétés que l'objet n'a pas forcément...
Vidéo intéressante, mais j'ai malgré tout un souci avec l'intro sur les Design Pattern. Cracher sur des diagrammes ou dire en demi-teinte que connaitre un pattern est inutile si on a pas déjà rencontré le problème associé, c'est quand même mettre de côté une capacité d'abstraction ou d'analyse qui me semble primordiale pour un développeur. Surtout avec dans la suite de la vidéo cette pique envers la production de code sans pousser la réflexion au-delà du "ça marche", il y a un vrai problème de cohérence. Pourquoi pousser la réflexion après avoir codé serait une bonne chose, et pas réfléchir en amont, penser des abstractions ?
"Pourquoi pousser la réflexion après avoir codé serait une bonne chose, et pas réfléchir en amont, penser des abstractions ?" Hello, je maintiens ma position ! 😉 "Over-engineering is often worst than under-engineering" - Refactoring, Martin Fowler (1999) Je constate chaque jour que c'est bien plus simple d'aligner une équipe sur la résolution d'un problème (l'épine dans le pied) plutôt sur une couche d'abstraction en soi (le meilleur framework/outil/design pattern..). Je constate également qu'un peu de dette de technique fait bien moins de dégât sur un projet que des couches d'abstractions pharaoniques (des semaines d'onboarding) pour résoudre des problèmes que l'équipe de dev n'a pas...
@@codeursenior Il y a quand même une énorme différence entre penser à l'avance et l'over-engineering. Vous exagerez mes propos pour ne pas répondre à ma remarque : l'incohérence de la vidéo. "Un peu de dette technique", pourquoi pas, mais il semble assez peu pertinent de se retrouver à résoudre des problèmes qu'on aurait pas eu en utilisant une méthode éprouvée, pour gérer un singleton par exemple, juste par principe ou a cause de l'épouvantail de l'over-thinking.
"il semble assez peu pertinent de se retrouver à résoudre des problèmes qu'on aurait pas eu en utilisant une méthode éprouvée" => Bien sûr, si vous connaissez déjà une méthode éprouvée en amont, je ne peux que vous inviter à l'utiliser. L'hypothèse cachée ici étant que vous savez déjà comment résoudre le problème au moment où vous le rencontrez.
@@codeursenior C'est un dialogue de sourd, vous vous contentez de détourner un extrait de mes propos à chaque réponse, sans répondre au point principal C'est assez malhonnête, on va s'arrêter là.
Pourquoi ne pas utilisé ici de l'héritage ? const snackbar = new SuccessSnackbar({message: "information", sticky: true}); Ou alors des méthodes statiques de création: const snackbar = Snackbar::createSuccess({message: "information", sticky: true})
Attention à l'anglicisme très présent chez les devs du mot "Consistant" qui veut dire "Cohérent" en français. Consistant ou consistance en français c'est pour les gâteaux 😉
Marrant, j'ai appris à construire des applis par les données par la méthode merise, je n'ai jamais été bloqué et je ne connais pas les design patterns.
je vois pas l'interet de faire un builder, un superclasse "BaseSnackbar" avec des attritbut privée aurait eu le meme effet. car dans la realité, les devellopeur vont juste modifier le builder pour faire ce qu'il veulent et en code review on leur dira "ah non non non, la durée est la meme pour toute les snackbar du projet"
Hello, merci pour votre retour. Est-ce que vous avez un exemple de code à partager à partir des spécifications présentées dans la vidéo ? Au plaisir d'échanger, Simon.
Juste en passant, les designs pattern hormis de très rares ne doivent pas être utilisés d'entrée de jeux. Il faut avant que le code et l'orientation business se stabilise avant de refactorer avec du design pattern. Sinon on risque de tordre le bras d'un design pattern pour lui faire faire un autre job. Et là c'est la merde. Avant de pensez design pattern, pensez SOLID. Pensez design d'objet par aggegat de comportement (interface). Plus tard refactorez via des design pattern "si et seulement si nécéssaire". Hormis la factory, peu doivent êtres utilisé from scratch.
Hm’ouais… je suis très départagé. Dire du builder pattern que c’est « Senior »… C’est un peu abusé quand même. Et pour ce cas de figure, je suis départagé entre créer une classe SnackbarBase et jouer sur de l’héritage ou employer le builder pattern.
Ce qu'il a utilisé n'est pas le builder pattern. C'est juste une classe avec des getters et des setters et des fonctions qui renvoient l’objet avec des valeurs prédéfinit. Si le mec est senior, il l'est dans l'amateurisme de ses solutions. Ton intuition est bonne en ce qui concerne d'avoir une meilleur solution que celle proposée dans la vidéo. Tu es sur la bonne voie.
@@pacoraby532 Tu es mignon et j’apprécie beaucoup ton gentil et charmant message, mais il est inutile d’autant dénigrer ce pauvre Simon. Ça me met plus mal à l’aise pour lui que ça ne me fait rougir de tes si agréables compliments. On va boire un verre ?
@@wanstalker107 J'ai juste appeler un chat un chat. En même temps on a une flopée maintenant de Codeur pseudos senior avec des techniques de coach de séduction. Le code qu'il propose est l'application d'aucun design pattern. C'est juste une classe qui se balade. Donc il devrait se sentir mal à l'aise étant donné qu'il raconte des conneries à grande échelle. Avoir une motivation mercantile n'a rien de préjudiciable tant qu'on ne trompe pas les gens sur le produit qu'on vend. Sinon ça s'appel une arnaque.
Un petit retour pour remercier Simon pour son travail. J'ai commencé Angular avec ton livre (génial), j'ai pris des stagiaires en les poussant sur Angular grâce à ton cours "Apprendre Angular", avant d'entrer en stage chez moi et ils sont maintenant en CDI de dev frontend Angular dans d'autres entreprises.
J'ai aussi suivi le cours de Simon "Maîtriser Angular en Entreprise" et c'est vraiment le top! Agréable à lire et le fait de comprendre chaque ligne de code sur un vrai projet a l'architecture solide est rassurant et très plaisant (j'aime encore plus Angular). Très complet ! Un grand merci de nous donner cette vision professionnelle du dev pour des étudiants qui n'ont pas forcement possibilité de faire des stages ou autre dans de vrais projet Angular. Cela permet de moins redouter l'entrée dans la vie pro. N'hésitez surtout pas !
Merci pour ton retour Maxime, ça me touche beaucoup. Je suis très fier d'avoir pu t'aider même d'un millimètre dans ton parcours. Excellente continuation à toi !
Vous avez vraiment un don pour réussir à rendre ces concepts complexes en quelque chose d'accessible et surtout de le faire avec une approche très concrète
Merci Kevin, je n'aurais pas pu lire de meilleurs compliments !
Mon objectif est de rendre toutes ces techniques accessibles à tout le monde.
Bon développement à vous,
Simon.
En tant que jeune apprenant suite à une reconversion, ta vidéo est incroyable ! Les explications et le codes sont très faciles à comprendre, tu es super pédagogue. Merci beaucoup
Merci, bon code à toi !
Comme toi à l'époque je ne savais pas trop comment les utiliser.
Mais après être tombé sur explication plutôt claire, pour un problème que j'avais rencontré, j'ai trouvé ça génial et passionnant.
Donc 100% ok pour que tu nous expliques d'autres design Patterns !
Salut Ben, merci pour ton retour.
C'est noté, on a donc 23 vidéos en tout à tourner. 😉
C'est un design pattern qu'il est bon de savoir, mais en vrai, en JS/TS, un simple objet options dans le constructor avec des valeurs par défaut (et des union type pour les propriétés "magic string") ça reste quand même plus confort (et beaucoup plus familier).
Ca permet aussi de plus facilement passer les options d'objet en objet si besoin (pas forcément un truc que je recommande, mais imaginons que, par example, tu aies un composant qui va afficher, entre autre, une snackbar, et que cette snackbar doit être configurable de l'extérieur)
Hello, discussion intéressante !
Effectivement, c'est l'approche "JS hacker" par défaut.
Mais par rapport à la problématique de la vidéo, comment fais-tu pour encapsuler des configurations ?
(Toutes les snackbars d'informations sont bleues, durent 3000 millisecondes, et ne peuvent pas être fermées).
Au plaisir d'échanger,
Simon.
@@codeursenior
Merci de la réponse !
Je ne dirais pas forcément que c'est une approche "JS hacker", mais une plus une approche qui respecte l'esprit des design pattern tout en prenant en considération les spécificités du language (ici Typescript avec le destructuring + default parameters).
Pour ce qui est de l'encapsulation, des paramètres valeurs par défaut dans ton objet d'options permettent de rester plus flexible et future proof : si tu ne précises pas , tu as les valeurs par défaut pour la couleur, le timeout etc, mais tu peux au besoin, un jour, overrider ça (je suppose que l'on connait bien tous les deux les demandes métier sorties du popotin qui te tombent sur le coin de la figure du jour au lendemain).
Si vraiment il y a besoin de dire "non, zut, les snackbar durent 3 secondes, point", tu as toujours plusieurs façons de faire, définir tes proçpriétés privées dans le constructeur (mouais), utiliser des valeurs hard codées vu que de toutes façons ce n'est pas configurable (mouais aussi mais dans le fond...), ou alors wrapper ça dans des factory qui vont envoyer les bons params "forcés", ce qui est une bonne approche car, encore une fois, ça te laisse une snackbar de plus bas niveau entièrement paramétrable si besoin.
@@darialyphia Hello, merci pour ton retour. J'ai une tâche de refactoring qui arrive bientôt donc je regarderai si je peux "casser" l'héritage de classe imposé par le Design Pattern Builder pour créer quelques choses de souple.
Mais j'ai encore un peu de mal à voir comment tu encapsule 4 configurations différentes juste avec des options par défaut dans le constructeur. Comment créer des relations entre les propriétés à l'initialisation de la snackbar ? (Si type=information, alors duration=3000 & icon=clochue, et propriétés non modifiable de dehors).
Quoi qu'il en soit j'irai tester ça sur le terrain, merci pour ton retour complet. 🙂
Bon développement,
Simon.
@@codeursenior pour cette problématique j'aurais utilisé des variants nommés (success, alert, error...), à partir de là tu peux tout conditionner, tu fais du pattern matching au besoin et tu mets juste une valeur par défaut dans ton constructor sur ce qui est commun
@@codeursenior T'es pas obligé d'utiliser des types primitifs dans ton ctor. Si le paramètre "message" à lui seul fait du sens pour ce cas d'utilisation, tant mieux. Mais si le paramètre "duration" ou "icon" ou un autre n'a pas de sens à lui seul, et que tu devras gérer des cas pénibles avec des relations entre les paramètres qui vont conduire à du bordel sans nom et un immense plat de spaghetti, alors, peut-être que passer un type spécialisé en paramètre aura plus de sens que de simplement utiliser des types primitifs.
A noter aussi que dans un cas comme celui que je décris, on s'approcherait un peu du concept d'injection de dépendance.
Merci de nous avoir fait découvrir ce pattern design. Chaque vidéo est toujours un régal! Bonne continuation!
Merci pour ton message @Amel !
Bonne continuation également,
Simon.
Merci pour ta chaine TH-cam, car tu fais évolué beaucoup EN FRANCE L INFORMATIQUE contre le Monde ANGLOPHONNE qui est Puissant dans le ce domaine!! Continue ta chaine youtube MERCI
Hello, merci beaucoup pour ton message, ça me va droit au cœur. Je vais tout faire pour honorer la mission 👍Et il n'y a pas qu'en informatique que le monde anglophone est (trop ?) puissant...
@@codeursenior Merci beaucoup mon amis, en ce moment j apprend l anglais depuis 6 mois et c 'est vraiment top
@@vincentbornert9427 Solide. À bientôt !
@@codeursenior oui merci continue tes vidéos surtout c est les meilleurs sur youtube en français je trouve car tu donnes les détails du vrai métier
@@vincentbornert9427 💪
Pour apprendre et surtout comprendre les Design Pattern, rien de mieux que le livre Design Pattern Tête La Première, ce bouquin est magique. Et contrairement à ce que tu dis, je conseille de le lire avant d'avoir rencontré les problèmes, car il expose justement très bien les problèmes et le chemin de réflexion qui mène jusqu'au Design Pattern étudié. 😊
Merci Simon très bonne vidéo.
On découvre toujours de meilleures façon de coder avec toi :)
Merci, objectif atteint pour moi alors. 💪
Bon développement,
Simon.
vidéo qui tombe a point nommée! je viens d'être embauché en Junior. Lors de l'entretien, j'ai été coincé sur la question des design pattern. J'y vois déjà plus clair. merci !
Merci, et bon courage pour tes entretiens !
Hello Simon. Je découvre ta chaine. Superbe vidéo. L'approche est excellente tout comme les explications. Bravo !
Hello, bienvenu à toi sur la chaîne alors ! Bon code et bientôt, Simon.
Incroyable... Je te remercie j'étais mais alors là EXACTEMENT dans la situation que tu décrivais en début de vidéo, j'avais beau lire des articles, ou voir des documents sur les designs pattern, je n'arrivais absolument pas à avoir la compréhension de l'utilisation d'un design pattern, et pour le design pattern builder tout autant, et là j'ai l'impression que tu m'as ouvert les yeux... Même si je expérimente pas en JavaScript, grâce à toi je pense pouvoir l'utiliser dans un cas concret en java et pour ça merci milles fois !
Pour le coup l'observer ou poids mouche sont aussi des concepts que je trouve intéressant par principe mais le fonctionnement me perd vraiment, je ne sais pas si tu as déjà fait d'autres explications de design pattern, mais celui là est une grande réussite de mon côté !
Merci pour ton retour, c'est top que tu sois débloqué sur ce design pattern !
Je compte abordé l'Observer également, je l'utilise quotidiennement. 👍
@@codeursenior Super ! Pressé de voir ça ! 😄
@@meijiao9766 Yep, je planche déjà sur cette mini-série. 👍
Merci Simon! Très bonne vidéo. Moi en tout cas, tu m'as réconcilié avec les Design Patterns.🙂
Merci pour ton retour, le but de la vidéo était justement ne plus être fâché avec les Design Patterns ! 💪
Objectif atteint donc. ^^
Bon développement à toi,
Simon.
Un grand plaisir à regarder, quand la tête est dans le guidon, ces vidéos permettent de se rappeler de la relever et de prendre le temps de penser ;))
"Prendre le temps de penser". Je n'aurais pas dit mieux, c'est clairement ce qui permet d'aller beaucoup plus vite à moyen et long terme. 👍
Bon développement à toi,
Simon.
Merci tu m'a fait comprendre des choses intéressantes sur ce design pattern ! Des vidéos sur les designs patterns c'est excellent. Si tu peux faire une petite série de vidéos sur ce sujet ce serai vraiment bien. C'est réellement une forte valeur ajouté de savoir utiliser et surtout QUAND utiliser un design pattern. Tes explications sont au top, j'ai 5 ans d'expérience dans le code donc j'ai un peu ( je dis bien un peu) d'expérience et vraiment j'ai trouvé cette vidéo Super explicite et Utile. D'autres stp !
Hello, merci pour ton message !
Je te confirme que je planche une petite série sur les Design Patterns, orienté 100% vrai-vie / développeur frontend. 👍
Bon développement,
Simon.
Le même réponse, malgré 10 ans d'expériences je n'ai jamais coder réellement comme ca mais ca donne envie. Je suis pour une série sur les design pattern aussi :)
Bonjour Simon, Merci pour la vidéo. Le sujet est bien aborder.
Merci à toi Samir ! 👍
Je me demandais justement si tout allais être assez clair, étant donné que les Design Patterns sont plutôt "abstraits" en soi.
Bon développement à toi !
Simon.
Je vois remercie pour ces explications , je commence à comprendre la nature du design pattern .
Merci André, c'est top de pouvoir rendre ces patterns plus "digeste". À bientôt
Waouh c'est tout simplement magnifique ! Je suis tombé amoureux des design patterns. Je ne comprenais pas trop leur nécessité mais maintenant, grâce à vous ce n'est plus le cas. Le code qui marche ne me suffit plus et je veux en apprendre plus. Svp pourriez vous présenter d'autres design ? Sur TH-cam ce n'est pas bien expliqué.
Bonjour, bienvenu au club des amoureux du bon code ! Si le code qui marche ne vous suffit plus, je veux que vous vous sentiez au BON ENDROIT sur cette chaîne. 💪
Vous trouverez la playlist de tous les design patterns expliqué sur la chaîne sur ce lien : th-cam.com/play/PLhVogk7htzNhf1sPcvTQzHV_Jv6-LOmLi.html
La playlist est en cours de construction, mais certains design pattern sont déjà disponible. Bon code à vous !
Salut Simon merci pour tes vidéos, elles sont très pertinentes. Je suis aussi formateur JavaScript mais j'ai 23ans, pas encore formateur Angular mais j’arrive je te rattrape ^^
Force à toi mon gar, force à toi.
Merci Abdoul ! 💪
Force, on en veut d'autres 😂
@@burdygoureige6619 Il va me falloir un peu de force pour les 22 autres Design Pattern effectivement. Je me met au boulot ! 😉
@@codeursenior Oui ça va te demander beaucoup de temps c'est sur! Ou Sinon ceux les plus utiles en côté front, ou les plus utilisés en angular. 🙂
@@burdygoureige6619 Oui carrément c'est une excellente idée. Je vais plutôt montrer le côté REEL de tout ça. Par exemple, je n'implémente jamais le Pattern Observer en Angular quand j'en ai besoin... puisque je peux simplement créer un Observable/subscribe(). Bref, vais présenter ça sous un angle de la vraie vie, côté frontend. 👍
À +,
Simon.
Super vidéo, tu m'as tellement réconcilié avec les design pattern que j'espère que tu vas en aborder d'autres !!!
Oui c'est prévu, j'espère trouver le temps qu'il faudra pour vous sortir tout ça ! 😉
Merci pour ta très bonne vidéo. Ça m'a donné envie d'aller plus loin dans mon code pour qu'il soit plus scalable. Merci à toi
Merci pour ton message, c’est le but des vidéos donc ça fait plaisir !
Bon développement à toi,
Simon.
Tes vidéos sont géniales. Je suis un dev react et je dois rapidement me former sur angular, j’intègre une entreprise dans deux semaines. Merci pour toutes tes vidéos. C’est clair, précis et ça permet de monter en compétence rapidement.
Tu aurais un lien sur le quel je peux trouver les principaux design patterns en angular ?
Merci 🤩
Merci beaucoup ! Je passe beaucoup de temps sur Symfony ces derniers temps et j'ai toujours eu du mal à comprendre l'intérêt de tout ces "Builders" mais ca devient de suite plus clair et je vois de quelle manière je pourrais implémenter ça dans mon propre code pour le rendre plus simple à utiliser. Encore merci :)
+1 like, +1 abonnement, + petit commentaire pour le référencement ;)
Merci pour votre retour et pour la contribution à l'effort de guerre.
Le Builder Pattern vaut le détour, il n'a pas pris une ride avec le temps. 😉
Magnifique pédagogie ! Bravo collègue !
Merci collègue ! 🔥
Merci simon c'est toujours un régal de suivre tes conseils
Merci Mohamed !
Bon développement,
Simon.
Hello Simon, C'est un concept dont j'ai beaucoup entendu parlé mais qui est toujours resté flou. Grâce à ta vidéo, j'ai compris l'utilité et la manière de le mettre en place en - de 5min. Merci :). Perso je suis preneur des autres explications sur les design pattern que tu utilises.
Merci pour ton retour, j'ai réussi ma mission avec cette vidéo ! 🔥
Je me note de faire une série de 23 vidéos sur les Design Patterns (il y en a 23 😉).
Bon développement,
Simon.
@@codeursenior Parfait ! bon courage :)
@@AlteriosLeGris Merci ! 🙂
Le code que tu affiche à 8:28, on vois que ta fait du copier/coller et que ta pas finis de renommer les variables car ta 2 fonctions qui sont incorrect ^^' (setSticky & setDuration).
Super vidéo, (je suis étudiant) j'ai toujours du mal à utiliser les design pattern et je me souviendrai de cette vidéo le moment voulu. Honnêtement je galère avec tous les design pattern mais les pires pour moi sont les abstact factory et les singletons donc si tu pouvais faire une vidéo dessus, ce serait top !
Merci pour la qualité de contenu tes vidéos
Impressionnant
Nous sommes sur les épaules d'un géant
Cela offre un regard une respiration une vision plus grande que notre imagination
Merci Pascal ! 🔥
Salut; est il possible de mettre un exemple de l'utilisation de la class sur l'html du snackbar?
Salut Michel,
Malheureusement, je ne pense pas que ce soit intéressant ici.
Cela créerait un anti-focus pour tout le monde, d'un cas d'utilisation de Snackbar dans le DOM. L'objectif ici est 100% d'illustrer le Design Pattern Builder.
En espérant que tu comprennes la démarche !
Bon développement,
Simon.
Bonjour Simon, j'aime bcp ces petites séries de vidéos courtes sur une notion spécifique en particulier. Dans le même format, un design pattern que j'aimerais bien voir c'est l'injection de dépendance. Ce serait bien d'avoir ton retour sur l'état de l'art de ce design pattern super important et qui aide beaucoup pour les tests. Super vidéo en tout cas👌
Très bonne idée !
Eh bien, je me note votre idée et je retourne plancher sur une petite série de vidéos sur les Design Patterns. 👍
Bon développement,
Simon.
quels seraient les huits premiers motifs de conception à apprendre en premier?
Suivant le critère de fréquence d'implémentation dans les codes Pro...
Excellentissime 😌❤️👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼
Merci à toi !
Bon développement et à bientôt,
Simon.
Hello Simon, j'ai essayé d'accéder à votre cours, Devenir fullstack javascript mais le lien ne fonctionne pas. Est-ce que le cours n'est plus disponible ?
Hello Laurent, de temps en temps je "ferme" le programme durant 1 mois lorsqu'on est complet. Pour le mois d'aout, le programme est ouvert actuellement.
Bon développement à vous ! Simon.
Merci pour tes vidéos.
Salut ce que tu appelle snack bar c'est une modal? Ou c'est pas vraiment la même chose ? Je suis sur ce sujet en ce moment, je dois créer une modal qui affiche du contenu dynamique via une api, et ça me rend un peu dingue 😊
Merci pour tes explications.
Programmant principalement en c++, je vois l'analogie de ces builders avec les fonctions membres static qui retourne une instance de la classe (ces fonctions ne dépendent d'aucune instance et sont appelées via "NomDeClasse::NomDeFonction(arguments)")
Peux tu faire des Tuto design patterns avec le Typescript? Ou javascript
Salut, oui les prochaines vidéos sur les Design Patterns seront en TypeScript !
(comme celle-ci d'ailleurs, tu as l'extrait de code dans la description de la vidéo 👍)
It was great explanation and great example. Thanks
Thank you for your positive feedback Ekrem !
bonjour simon, j'appreci beaucoup tes videos, juste une remarque sur la solution builder que tu as expisé, ca casse le principe OCP, un bon polymorphisme avec le pattern Stategy t'aurais donné un meilleurs resultat
Hello Amine, merci pour ton retour. Oui c’est une piste intéressante, surtout que ça me permet de passer par la composition plutôt que l’héritage. La problématique que j’avais m’a poussé à partir sur le builder, car je dois créer un objet de configuration à passer une librairie. Je ne coder qu’un wrapper.
Au plaisir d’échanger,
Simon.
Simon une question : quel est l'importance d'utiliser redux ou ngrx store dans angular si c'est important si tu pouvais une une vidéo dessus
Salut Mohamed, je citerai l'adage classique : "Si vous ne savez pas si vous avez besoin de Redux, c'est probablement que vous n'en avez pas besoin".
Est-ce que ça t'éclaire ou pas du tout ? 🙃
@@codeursenior ah oui j'ai compris
@@sogobamohamed4563 😉
c'est hyoer bien expliqué!!
Super, merci pour ton retour. L'objectif est vraiment de rendre accessible un savoir qui me paraissait plus opaque à l'époque.
Super cet exemple de snackbars, on a eu exactement le même problème à mon boulot c'est fou !
Étonnant ! 😅
eureka !!! top l'explication du builder ;) aller je m'abonne
Waaa excellent 😎 merci
Merci, bon développement. 👍
Salut Simon, je suis nouveau sur la chaîne, j'aurais une question pour toi, ça serait pour savoir si, dans le monde du travail, les développeurs commences directement à faire du code propre ou bien à faire du code qui fonctionne ?
Sinon, super vidéo, j'ai appris un truc très intéressant.
Merci.
Hello Damien, quel que soit le niveau d'un développeur, je pense que le code que l'on produit passe toujours par ces étapes :
Make it work > Make it right > Make it fast.
C'est plus une trajectoire à viser qu'une réponse OUI/NON à un instant t.
Voilà ! :)
Bon développement,
Simon.
' return new Snackbar (...) ' dans le build, il faut faire une autre class Snackbar avec un constructor ?
Bonjour @Makes, oui tout à fait. Précision que j'aurais peut-être dû apporter. En fait, c'est SnackbarBuilder qui va gérér la création des Snackbars. Mais Snackbar est une classe également, qu'on pourra rendre protégée et accessible au Builder. Ainsi, on est obligé de créer des instances de snackbars en passant par le builder comme on le voulait. 👍
@@codeursenior ok merci 😃
@@codeursenior Peut-on faire comme ceci aussi ?
private build() {
return ({
message: this.message,
title: this.title,
sticky: this.sticky,
type: this.type,
icon: this.icon,
canClose: this.canClose,
duration: this.duration
})
}
@@makes5819 👍
@@polipos8341 Oui, c'est une possibilité, mais je pense que tu perdras le typage TypeScript sur l'élément Snackbar retourné. Peut-être ajouté "as Snackbar" et créer une interface snackbar.model.ts ?
Merci pour ces explications! Je réalise maintenant que j'aurais pu utiliser ce pattern dans un projet à la fac ahahah
😂 Haha, c'est la première étape pour apprendre les Design Patterns... Se rendre compte qu'on aurait pu en avoir besoin !
Bon courage pour la Fac, je suis passé par là...
Simon.
private setDuration(duration: duration)
{ this.icon = icon; return this; }
Pourquoi icon ici ?
Salut Yamine,
Pure erreur d'inatention au milieu du montage/tournage.
C'est bien un setter "classique" pour ce design pattern:
````
private setDuration(duration: number) {
this.duration = duration;
return this.
}
```
Je viens de mettre à jour le code dans la description de la vidéo. Merci !
Très utile, Merci beaucoup
Merci ! 👍
je n'arrive pas a bien saisir sur le fond la différence avec une factory, sur la forme ca permet l'autocompletion je suppose mais sur le fond, on a les elements en commun au niveau de la classe abstraite et les specificites au niveau de chaque classe d'heritage,
Bonjour, le Factory pattern crée des objets en fonction d'un type spécifié sans exposer la logique de création, tandis que le Builder pattern construit un objet étape par étape, permettant de créer des variantes complexes de cet objet. C'est l'étape d'abstraction supplémentaire, quand la compléxité de création devient trop lourde à exposer.
Pourrais tu nous faire une introduction au logging (journal d'erreur) ? comment l'integrer ? que faut-il y ecrire ou non ? comment regler different niveau si necessaire et sur quels critères ?
C'est rarement abordé mais ça me parrait essentiel pour trouver et resoudre des problemes qui eux n'apparaissent pas dans les compilateurs.
Je pense qu'il y a un copier/coller malencontreux sur setDuration (8min28. Merci pour la vidéo, je vais essayer de passer un peu de temps sur ces design pattern avec lesquels je ne suis pas très familier
Salut Jean-Bernard, effectivement pour le setDuration, c'est bien `this.duration = duration`. Bien vu ! 😉
Bon développement à toi, j'espère que tu auras l'occasion d'implémenter quelques Design Patterns sur du code récurrent !
Trop class, thkx.
Merci et bon code ! Simon.
Merci bien. J'ai toujours du mal à me manger du code qui réponds à des besoins que je n'ai pas encore eu, et j'ai souvent besoin d'un "historique" ("on fait ça parce que d'abord on a fait comme ça et ça marchait, mais ensuite on a voulu étendre à quelque chose de + général/durable/facile à entretenir et du coup on fait ceci ou cela plutôt maintenant"). J’apprécie donc particulièrement quand on me "dénoue" un truc en lui rendant du sens. Tellement + facile et + excitant d'avancer quand on comprend le sens , le pourquoi des choses... 👍
Merci pour votre message, c'est exactement le type de pédagogie que j'essaye de mettre en avant. Se mettre d'accord sur le problème avant la solution ! 👍
Bonjour Simon, dsl de passer par là mais je sais pas si tu captes encore les messages sur library... je suis devenu un de tes clients mais j'ai eu un petit problème. Merci de ton retour.
Holà, pas de soucis, on règle ça par email du coup.
Bon apprentissage à toi, 😉
Simon.
Bonjour Simon content de pouvoir te retrouver.
J'ai une petite question stp:
--> Aurais tu une référence de site pour creuser le sujet ? Avec une liste de design pattern les plus couramment utilisés.
J'espère que la question n'a pas été déjà posée. Je t'avoue que je n'ai pas eu le courage de lire tous les commentaires.
Je suis bien sûr entrain de chercher mais j'aimerai avoir ton avis stp.
J'ai vu ce "disign patern" dans une librairie que j'utilise pour filtrer un mot de passe. J'ai trouvé ça tellement beau et efficace et je me demandais justement comment cela fonctionnais.
--> Merci donc pour les explications !!!
Salut Nicolas, ça fait plaisir d'échanger à nouveau. J'espère que tu vas bien ! 😉
La référence que j'utilise pour les design patterns est le site REFACTORING GURU : refactoring.guru/fr/design-patterns.
Tu trouveras les 23 designs patterns référencés par le Gang Of Four (1994) avec des explications sympas.
Bon développement et à bientôt,
Simon.
Merci beaucoup pour l'info, oui ca serait cool de mieux expliquer ce concept de design pattern...
J'attends d'autres videos et je vais voir qlq tutos sur ca également.
Merci beaucoup
Merci, quelle est le pattern pour les méthodes avec beaucoup trop d'arguments, certains inutiles parfois et qui est vilain à lire. J'ai pensé au pattern command mais je suis pas sûre .
Bonjour, c'est un peu plus subtil que ça.
Pas sûr qu'il y est une recette côté Design Pattern sur les méthodes avec trop d'arguments.
Peut-être regardé du côté Clean Code/Refactoring pour ce genre de soucis. Plus de 1 ou 2 arguments indique généralement un problème de conception.
Bon développement,
Simon.
Bon exemple de mise en pratique du pattern. As-tu une idée de comment simplifier la pile de "if not null" à l'affichage de la Snackbar? Peut-être en appliquant des Decorators, ce n'est pas "simple" mais ça permet de ne pas risquer de tout casser si l'on doit changer la manière d'afficher une seule des propriétés de la snackbar.
Sinon tu pourrais également démontrer le fonctionnement de Bridge pour afficher les différentes notifications mais dans différents contextes (desktop/mobile, ou visitor / admin par exemple).
Ce serait également intéressant que tu montres la correspondance du code avec le diagramme UML si cela ne te saoûle pas trop. En fait ces diagrammes sont plus simples que l'on ne le pense , une fois que l'on a compris leur équivalent en code.
Salut Sylvain,
Effectivement, j'ai prévu de faire plusieurs vidéos pour présenter les 23 design patterns référencés par le Gang Of Four dans un contexte Frontend/JavaScript.
Je manque un peu de temps en ce moment mais c'est bien sur ma todo-list de vidéos. ;)
Côté diagramme je vais réfléchir, malheureusement cela ne m'as jamais aidé à réellement comprendre l'intérêt des design patterns par rapport à du code "en action".
A voir si je change d'avis !
Bon développement,
Simon.
@@codeursenior C'est une bonne idée de série, qui peut représenter énormément de travail pour couvrir les 23!
Je pense que les plus intéressants ce sont les patterns que tu as personnellement utilisé en mission et ou en poste.
Après l'UML c'est au goût de chacun, personnellement, cela m'aide de réfléchir en abstraction plutôt que directement en coe, mais chacun sa méthode.
@@sylvainschellenberger Oui, je pense aussi prioriser les vidéos sur les design patterns les plus utiles au quotidien ! 👍
merci , peut etre le code source ?
Bonjour, j'ai essayé de mettre le code source dans la vidéo à 11:21. Est-ce que c'est lisible ou pas du tout ?
Sinon je peux regarder pour l'ajouter en description. Ce serait peut-être une meilleure solution.
@@codeursenior désolé ce n'est pas lisible
@@nuketoto3868 Re, effectivement ce n'est pas la joie !
Je viens d'ajouter le code du Design Pattern Builder à copier-coller en description de la vidéo 👆
Est-ce que tu as pu le récupérer ?
Je pense que cela devrais servir à d'autres développeurs également !
@@codeursenior oui, c'est bon. super, merci !
@@nuketoto3868 Au top !
J'ai un probleme justement et je me demande si ya un patern pour ca... Exemple on demande a une fonction de nous donner la personne Patrick donc on fait un espece de getPersonne ( aName : string ) : TPersonne; ca retourne une personne mais la on doit prendre en charge le fait que la fonction a instancier la personne mais c'est nous qui doit le detruire... Parcontre peut etre quon veux pas le detruire car cette personne la doit etre utiliser un peux partout dand notre code... Bref je me demande si je dois garder en note tout les personne cree, exemple dans un tableau de la class personne qui delete tout les personne a la fermeture du programme ... Bref personne c'est un objet simple mais j'ai des objet des fois comme ca qui doit etre refiller a plusieur autre objet qui me demande cette objet ... Mon probleme : c'est objet la qui me demande ma personne pense quil vont devoir le detruire eu aussi. Si il le detruit moi je tombe sur un null object error lollll
Hello Patrick, je vais vous donner mon point de vue à partir de ce que j'ai compris.
Premièrement, les Design Patterns ne sont pas des recettes de cuisines. Parfois, on peut "ne pas avoir suffisamment le problème" pour justifier de mettre en place un design pattern.
Deuxièmement, j'ai l'impression que vous avez un problème de state management classique : est-ce que j'ai déjà récupéré cette donnée ? est-ce que je veux une version à jour ou le résultat de la dernière requête ? Comment prévenir les autres éléments du programme que l'état a changé dans l'application ?
Je vous recommande de regarder du côté des principes Redux et Flux.
Bon développement !
Simon.
@@codeursenior Redux et Flux je connais pas.. merci je vais etudier ca un peux. C'est bien d'avoir des nouveau chemin a etudier, qui sais peut etre ma solution vas me venire... Je pense a une variable owner qui dit qui a le droit de detruire...
@@1234myflash Si vous n'avez pas de gros besoins d'industrialisation, une simple variable et un service dédié peuvent suffire ! 😉
Salut,
-tu devrais éditer cette coquille du code de la description : "setSticky(sticky: string)" -> "setSticky(sticky: boolean)".
-ne manquerait-il pas les attibuts au début de la class, par exemple :
class SnackbarBuilder {
private message: string;
private title: string;
private sticky: boolean;
etc
?
-je ne comprends pas : Il existe toujours une class Snackbar publique :
"class Snackbar {
constructor(
private message: string,
private title: string,
private sticky: boolean,
private type: string,
private icon: string,
private canClose: boolean,
private duration: number,
) {}
}"
puisque la méthode "private build() {return new Snackbar..." en a besoin, non ? Du coup l'utilisateur peut toujours l'utiliser à la place du SnackbarBuilder pour construire des snackbars farfelues, ou quelque chose m'échape ?
Pour le premier point, vous avez raison, mais malheureusement malheureusement je ne peux pas modifier les vidéos TH-cam. Concernant le deuxième point, il s’agit d’une astuce de syntaxe, de type script qui permet d’éviter cette redondance. Concernant le troisième point, il est effectivement possible de créer une snack-bar « libre » en sortant du contexte du Snackbar Builder. Selon le niveau d’abstraction dont vous aurez besoin, sur un gros projet, cette façon de faire pourrait être revue. Bon code !
Topissime merci
Merci Nicolas !
Excellent
Pour refact sans casser l'existant, les fonctions du genre CreateWarningSnackBar('message...', {...otherProps}); peuvent aider
Sujet très intéressant, même pour quelqu'un qui fait pas d'angular
Dans ton cas, ça suffit pas de passer tes props dans un objet et de juste mettre des valeurs par défaut ?
Ca donnerait une utilisation genre new Snackbar({title: "foo", message: "foo"}), constructor({title = null, message = null, canClose = false, ...}: { title?: string | null...)
Je délire peut être complètement je fais que du react
J'aime beaucoup cette approche j'aurai choisi le pattern Factory mais je trouve cette démarche plus élégante et plus simple à l’utilisation.
Très intéressant, tu expliques mieux l'utilisation des designs pattern
Merci ! 🔥
Je me souviens Dans mon apprentissage ING informatique, Je me souviens Des set et get voila de l'utilité montrer dans votre formation. Parfois Les techniques dev pro permet de devlopper le plus simple,mais l'apprentissage de ces techniques demande de la patience.
Comme dit dans la vidéo le niveau de précision est en fait que la lecture du code devient plus agréable et compréhensible par n’importe quel autre dev.
Hello Daniel, oui je suis 100% sur cette ligne.
Bravo pour cette vidéo, t'explique clairement et calmement. On voit ta passion pour le code ca fait plaisir 😜.
Je comprends l'intérêt de ce builder mais, de mon point de vue ce qui m'embête c'est cette duplication de code sur les BuildInfo() etc...
Potentiellement t'as des devs qui vont suivre cette exemple et mettre une 50ène buildMachin() et si un jour il y a besoin de modifier un comportement pour chaque fonction ça peut devenir l'enfer
Hello JohnV,
Merci pour ton retour constructif, voici mes réponses point par point :
- Au niveau des méthodes de builds, je ne pense pas qu'il y ait de duplication de code.
Au contraire, chaque build possible exprime à la ligne près la configuration à encapsuler.
- Aussi, si chaque build exprime une configuration spécifique, normalement, il faudra modifier uniquement cette méthode de build en cas de changement. (Principe Open/Closed de SOLID).
- Si jamais le business décide de changer les 4 configurations de build, et bien là, c'est notre boulot d'adapter les 4 méthodes. On n'aura pas le choix. 😇
Qu'en penses-tu ?
Au plaisir d'échanger,
Simon.
Les explications sont limpides, peut être un peu abruptes pour des juniors, mais avec un peu de notions ça glisse super bien. Étonnant que tu n’aies pas plus d’abonnés 🤔
Merci ! 🔥
Bien vu. Je ne fais pas de web mais cette problématique est universelle. Intuitivement je préfère toujours avoir un constructeur non tyrannique, mais tu apportes ici du sens. Notamment sur la consistance/cohérence.
Hello, merci pour ton retour !
je prefere les constructeurs avec un hash qui donne que les options necessaires, et le constructeur gere les valeur par defaut, ça evite davoir des setter inutile qui traine dans le code de la class et dans l'utilisation, je trouve pas ça tres propre. Le seul probleme de la version "pas senior" c'est qu'en gros on ne sait pas quel param correspond à quoi et qu'on est obligé de passer tous les param, ce qui est idiot
Tu vas tous les expliquer ?
Bonjour Vira, oui, on pourrait. Certains sont plus utiles que d'autres pour un écosystème frontend. Le sujet vous intéresserait ?
@@codeursenior tout à fait, le sujet est finalement extrêmement peu abordé sur le youtube francophone
@@toofitoutflemme Eh bien on a de quoi faire étant donné que le "Gang Of Four" a répertorié 23 Design Patterns... Donc 23 vidéos ! 🙂
Oui d'autres !! l'OL
@@burdygoureige6619 🔥
merci boss
Avec plaisir, bon code !
De mon côté, c'est le livre design pattern Java, la tête la première qui m'a mis une claque dès le premier pattern (stratégie)
🤯
Ah les livres... le moyen de progresser le plus sous-côté ! Bravo à vous donc !
(La série de livres de cet éditeur a une excellente réputation, votre commentaire vient le confirmer une fois de plus !)
Merci, je comprends mieux l'intérêt des design pattern.
Merci pour ton retour David, objectif de la vidéo réussi alors ! 👍
Dans toutes les boites que j ai faite on utilisait très rarement ce design pattern. Par contre factory constructor avec un defaut constructor private ça c'est très souvent
Chouette vidéo ! "N'utilisez pas constructor" mouhahahaha ! Ou comment rendre un dev curieux.
Merci pour votre retour ! J'espère que la vidéo vous a été utile au-delà de la curiosité initiale. :)
Bon développement,
Simon.
Wesh babor c'est mis à la prog ?
Wesh wesh
Merci
👍
Salut,
Ce design pattern que tu expliques me fait simplement penser à la POO avec héritage...
Les propriétés communes dans la class mère
Les propriétés spécifiques dans une class dérivée
Intérêt majeur : l'assistance de l'IDE
Un objet de la class dérivée aura accès uniquement aux propriétés et méthodes de son type (class dérivée)
L'autocomplétion ne proposera que les propriétés et méthodes de son type (class dérivée) contrairement au design pattern builder
Alors qu'avec le design pattern builder l'autocomplétion propose des propriétés que l'objet n'a pas forcément...
Sur les bulder tu peux utiliser des wither à la place des setter. Ça sera plus naturel à lire
T'as changé depuis ton procés Babor
Mince, tu m'as démasqué !
Vidéo intéressante, mais j'ai malgré tout un souci avec l'intro sur les Design Pattern. Cracher sur des diagrammes ou dire en demi-teinte que connaitre un pattern est inutile si on a pas déjà rencontré le problème associé, c'est quand même mettre de côté une capacité d'abstraction ou d'analyse qui me semble primordiale pour un développeur. Surtout avec dans la suite de la vidéo cette pique envers la production de code sans pousser la réflexion au-delà du "ça marche", il y a un vrai problème de cohérence. Pourquoi pousser la réflexion après avoir codé serait une bonne chose, et pas réfléchir en amont, penser des abstractions ?
"Pourquoi pousser la réflexion après avoir codé serait une bonne chose, et pas réfléchir en amont, penser des abstractions ?"
Hello, je maintiens ma position ! 😉
"Over-engineering is often worst than under-engineering" - Refactoring, Martin Fowler (1999)
Je constate chaque jour que c'est bien plus simple d'aligner une équipe sur la résolution d'un problème (l'épine dans le pied) plutôt sur une couche d'abstraction en soi (le meilleur framework/outil/design pattern..).
Je constate également qu'un peu de dette de technique fait bien moins de dégât sur un projet que des couches d'abstractions pharaoniques (des semaines d'onboarding) pour résoudre des problèmes que l'équipe de dev n'a pas...
@@codeursenior Il y a quand même une énorme différence entre penser à l'avance et l'over-engineering. Vous exagerez mes propos pour ne pas répondre à ma remarque : l'incohérence de la vidéo.
"Un peu de dette technique", pourquoi pas, mais il semble assez peu pertinent de se retrouver à résoudre des problèmes qu'on aurait pas eu en utilisant une méthode éprouvée, pour gérer un singleton par exemple, juste par principe ou a cause de l'épouvantail de l'over-thinking.
"il semble assez peu pertinent de se retrouver à résoudre des problèmes qu'on aurait pas eu en utilisant une méthode éprouvée" => Bien sûr, si vous connaissez déjà une méthode éprouvée en amont, je ne peux que vous inviter à l'utiliser.
L'hypothèse cachée ici étant que vous savez déjà comment résoudre le problème au moment où vous le rencontrez.
@@codeursenior C'est un dialogue de sourd, vous vous contentez de détourner un extrait de mes propos à chaque réponse, sans répondre au point principal C'est assez malhonnête, on va s'arrêter là.
Pourquoi ne pas utilisé ici de l'héritage ?
const snackbar = new SuccessSnackbar({message: "information", sticky: true});
Ou alors des méthodes statiques de création:
const snackbar = Snackbar::createSuccess({message: "information", sticky: true})
Attention à l'anglicisme très présent chez les devs du mot "Consistant" qui veut dire "Cohérent" en français. Consistant ou consistance en français c'est pour les gâteaux 😉
c'est clair sa me dégoute tout sa xD merci d'avoir rendu digeste ce truc ,simon thanks
La guerre contre les powerpoints et autres diagrammes a officiellement commencé ! 😆
Atos 😱😱😱
Un atosien ?
👍
🔥
Marrant, j'ai appris à construire des applis par les données par la méthode merise, je n'ai jamais été bloqué et je ne connais pas les design patterns.
Incroyable.
Même réaction que toi en comparant les solutions : Eurêka ! 😂
Refactoring Guru
Oui le site de référence. 👍
je vois pas l'interet de faire un builder, un superclasse "BaseSnackbar" avec des attritbut privée aurait eu le meme effet.
car dans la realité, les devellopeur vont juste modifier le builder pour faire ce qu'il veulent et en code review on leur dira "ah non non non, la durée est la meme pour toute les snackbar du projet"
Hello, merci pour votre retour. Est-ce que vous avez un exemple de code à partager à partir des spécifications présentées dans la vidéo ?
Au plaisir d'échanger,
Simon.
Juste en passant, les designs pattern hormis de très rares ne doivent pas être utilisés d'entrée de jeux. Il faut avant que le code et l'orientation business se stabilise avant de refactorer avec du design pattern. Sinon on risque de tordre le bras d'un design pattern pour lui faire faire un autre job. Et là c'est la merde.
Avant de pensez design pattern, pensez SOLID. Pensez design d'objet par aggegat de comportement (interface). Plus tard refactorez via des design pattern "si et seulement si nécéssaire".
Hormis la factory, peu doivent êtres utilisé from scratch.
Commentaire extrêmement pertinent !
Je plussoie (SOLID, composition vs héritage) 👍
11:21😂
Hm’ouais… je suis très départagé. Dire du builder pattern que c’est « Senior »… C’est un peu abusé quand même. Et pour ce cas de figure, je suis départagé entre créer une classe SnackbarBase et jouer sur de l’héritage ou employer le builder pattern.
On est sur un titre TH-cam ne l’oubliais pas.
Ce qu'il a utilisé n'est pas le builder pattern. C'est juste une classe avec des getters et des setters et des fonctions qui renvoient l’objet avec des valeurs prédéfinit.
Si le mec est senior, il l'est dans l'amateurisme de ses solutions.
Ton intuition est bonne en ce qui concerne d'avoir une meilleur solution que celle proposée dans la vidéo. Tu es sur la bonne voie.
@@pacoraby532 Tu es mignon et j’apprécie beaucoup ton gentil et charmant message, mais il est inutile d’autant dénigrer ce pauvre Simon. Ça me met plus mal à l’aise pour lui que ça ne me fait rougir de tes si agréables compliments. On va boire un verre ?
@@wanstalker107 J'ai juste appeler un chat un chat. En même temps on a une flopée maintenant de Codeur pseudos senior avec des techniques de coach de séduction.
Le code qu'il propose est l'application d'aucun design pattern. C'est juste une classe qui se balade.
Donc il devrait se sentir mal à l'aise
étant donné qu'il raconte des conneries à grande échelle.
Avoir une motivation mercantile n'a rien de préjudiciable tant qu'on ne trompe pas les gens sur le produit qu'on vend.
Sinon ça s'appel une arnaque.
@@pacoraby532 Le builder pattern s'applique sur la classe SnackbarConfig uniquement.