Le Design Pattern Contre-Intuitif le plus utilisé par les Développeurs Professionnels...
HTML-код
- Опубликовано: 1 окт 2024
- 👨🏻💻 Démarrer votre carrière de développeur PRO avec Angular :
www.angularsen...
Dans cette vidéo, j’aimerais vous dire pourquoi j’ai détesté les "Design Patterns" pendant des années.
Je voyais ces graphes avec 70 classes...
C’était incompréhensible et ça me dégoutait, car je n’ai jamais compris à quoi cela pourrait réellement me servir dans la vraie vie !
Je vais donc vous partager une discussion privée que j’ai eue avec un développeur Senior lorsque j’étais à Atos et qui m’a permis aujourd'hui de comprendre RÉELLEMENT à quoi pourrait me servir les Design Patterns.
Bon visionnage,
Simon.
🖥 CODE DU DESIGN PATTERN BUILDER (TYPESCRIPT) 🖥
Le code de cette vidéo à "copier-coller" et à adapter à vos projets.
```
// Design Pattern "Builder" with TypeScript //
class SnackbarBuilder {
constructor(message: string) {
this.message = message;
}
setTitle(title: string) {
this.title = title;
return this;
}
setSticky(sticky: string) {
this.sticky = sticky;
return this;
}
private setType(type: string) {
this.type = type;
return this;
}
private setIcon(icon: string) {
this.icon = icon;
return this;
}
private setCanClose(canClose: boolean) {
this.canClose = canClose;
return this;
}
private setDuration(duration: number) {
this.duration = duration;
return this;
}
buildSuccess() {
this.setType('success');
this.setDuration(3000);
this.setCanClose(false);
return this.build();
}
buildInfo() {
this.setType('information');
this.setDuration(3000);
this.setCanClose(false);
return this.build();
}
buildWarning() {
this.setType('warning');
this.setCanClose(true);
return this.build();
}
buildError() {
this.setType('error');
this.setCanClose(true);
return this.build();
}
private build() {
return new Snackbar(
this.message,
this.title,
this.sticky,
this.type,
this.icon,
this.canClose,
this.duration
);
}
}
// Use case //
const snackbar = new SnackbarBuilder(message)
.setSticky(true)
.buildInfo();
```
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.
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.
T'as changé depuis ton procés Babor
Mince, tu m'as démasqué !
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
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) 👍
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é. 😊
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})
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
Pour refact sans casser l'existant, les fonctions du genre CreateWarningSnackBar('message...', {...otherProps}); peuvent aider
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 😉
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)")
Informations et façon de faire très intéressante, par contre 13min pour expliquer ce qui se trouve en ... 1min en cherchant les bouts de codes et un gros résumé de la problématique.. bon...
Ce n'est pas le pattern builder car c'est plus complexe à mettre en place et ce dont ce que tu présentes ne respecte donc pas le premier pilier de SOLID
"S" : Single responsibility
La tu as fait une classe qui a plusieurs responsabilité.
Ni le second pilier "O" : Open/closed principle
Puisque si demain tu décides de changer ta manière de faire les choses alors tu devras modifier ta classe SnackbarBuilder...
Bref regarde le diagramme de classe pour le pattern builder
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).
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 🤩
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 RUclips. 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 !
Développeur Junior lambda ou développeur junior de lambda ?
Hu hu, humour de dev.
Très franchement ce n'est pas le DP le plus utile du monde. Surtout que sur les langages supportants le polymorphisme, il suffit de déclarer plusieurs constructeurs dans l'objet, plutôt que de faire une classe externe qui ne sert à rien ...
Et même sur des langages sans polymorphisme, tu trouves parfois des solutions élégantes. En Dart par exemple tu peux écrire SnackBar.info(title: "TonTitre", sticky: true) pour appeler le constructeur "info", et utiliser des paramètres nommés optionnels. C'est beaucoup plus clair.
L'intérêt du builder est trèèèèèèèèès restreint, voir inexistant.
P.S.: Dans ton exemple final du builder, tu auras pu mettre un bel enum pour les différents types de snackbar, plutôt qu'en dur comme ça ;p
Hello Bernard, merci pour ton retour, c'est intéressant.
Concernant la problématique de la vidéo, est-ce que tu aurais une implémentation TypeScript à partager, avec les propositions que tu suggères ?
Je suis toujours à la recherche de la meilleure solution possible, si j'ai l'occasion de challenger le code, ce sera top. 💪
Au plaisir d'échanger,
Bon développement,
Simon.
@@codeursenior ça va être assez embêtant, car sur RUclips on ne peut pas partager de lien, mais oui sur typescript tu as une méthode plus élégante que le builder :
class Snackbar {
title: string;
type: string;
static infoSnackbar(titleValue:string): Snackbar {
return new this(titleValue, 'info');
}
static errorSnackbar(titleValue:string): Snackbar {
return new this(titleValue, 'error');
}
constructor(titleValue:string, typeValue:string) {
this.title = titleValue;
this.type = typeValue;
}
}
var snak1 = Snackbar.infoSnackbar("toto");
var snak2 = Snackbar.errorSnackbar("tata");
console.log(snak1.type);
console.log(snak2.type);
Tu utilises une méthode statique pour construire l'objet via le constructeur qui lui aura tous les paramètres.
Cela t'évite de créer une classe inutile, et tout reste dans le même fichier.
Et la méthode d'instanciation est, je trouve, plus élégante :)
@@bernardnaques2951 Salut Bernard, je vais me noter une tâche technique de tester ça au boulot ! 🔥
Effectivement, je suis très intéressé par ta solution : 1 seul fichier, moins de code... que du bonheur.
Ma seule "inquiétude", c'est que je dois gérer jusqu'à 3 paramètres optionnels de mon côté : 1 titre, 1 éventuelle traduction dynamique et 1 paramètre isSticky.
Donc, je pense obtenir quelque chose comme ça :
const worstSnackbar = Snackbar.info("message", "title", { translateKey: translateValue}, true).
Et là ce qui me chiffonne, c'est que j'ai une fonction avec 4 arguments dont 1 flag (booléen).
De ce que j'ai lu dans Clean Code de Robert C. Martin, c'est d'éviter des arguments booléens et plus de 2 arguments par fonctions ("Code Smells").
Est-ce qu'il y aurait moyen de chaîner la construction de l'objet avec des méthodes statiques ?
Je n'ai pas pris le temps d'essayer.
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 ! 🔥
eureka !!! top l'explication du builder ;) aller je m'abonne
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. 😉
Même réaction que toi en comparant les solutions : Eurêka ! 😂
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.
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. 😉
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 RUclips 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 : ruclips.net/p/PLhVogk7htzNhf1sPcvTQzHV_Jv6-LOmLi
La playlist est en cours de construction, mais certains design pattern sont déjà disponible. Bon code à vous !
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.
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 !
La vidéo commence tu me sors un constructeur avec des paramètres qui vont dans tous les sens et tu dis "ça me parait bien". Tu es sérieux là lol ?
Mais ça me tue ce genre de vidéo dans le sens ou ça me fait rigoler ou ça me déprime.
Mec tu as rien compris à l'orienté objet, tu as rien compris aux design pattern et tu as rien compris au builder pattern.
Ce que tu as codé n'est PAS le builder pattern.
Il a quoi de complexe ton objet ? RIEN. Alors déjà pourquoi même tu veux utiliser un builder pattern ?
Ce que tu as codé est juste une classe (avec des getters et des setters et des functions qui renvoient l'objet avec des valeurs prédéfinit) qui a le mot builder dans son nom lol.
Il est ou le pattern explique moi lol ?
Moi je suis un dev qui passe derrière toi et je voix ça, je delete le file et je recode tout.
Et avec ta vidéo ta connerie va se répandre ...... bien joué.
Vous êtes libre de proposer une vidéo alternative et de me poster le lien. Ce sera avec plaisir que je mettrai ce lien vers votre vidéo et nous laisserons les développeurs avoir accès aux 2 versions.
C'est vraiment pénible les airpod...
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.
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.
Oui ! Une version vf et augmenté de l'introduction sur les patern par Fireship svp : ruclips.net/video/tv-_1er1mWI/видео.html
Merci 🙏
Merci pour l'inspiration, Fireship est une chaîne exceptionnelle.
Excellentissime 😌❤️👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼
Merci à toi !
Bon développement et à bientôt,
Simon.
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.
11:21😂
Magnifique pédagogie ! Bravo collègue !
Merci collègue ! 🔥
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.
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.
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.
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é ! 😆
Merci pour tes vidéos.
Excellent
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.
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.
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.
Faut pas trop en abuser non plus de ca
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 !
Refactoring Guru
Oui le site de référence. 👍
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.
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.
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 😊
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...
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.
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 pour ta chaine RUclips, 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 💪
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 ^^
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
👍
🔥
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à.
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 ! 😉
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 !
Wesh babor c'est mis à la prog ?
Wesh wesh
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 ! 🙂
Parle du pattern observer
Hello, excellente idée, surtout qu'avec RxJS dans Angular, on va se régaler.
C'est ajouté à la "to-do list" des vidéos à réaliser !
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 🔥
Trop class, thkx.
Merci et bon code ! 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
Mercy tyyh
Merci !
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 ! 👍
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.
Waaa excellent 😎 merci
Merci, bon développement. 👍
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.
Atos 😱😱😱
Un atosien ?
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.
Sur les bulder tu peux utiliser des wither à la place des setter. Ça sera plus naturel à lire
Topissime merci
Merci Nicolas !
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 !
merci boss
Avec plaisir, bon code !
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.
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 !
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.
Merci
👍
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 !
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 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.
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.
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.
Merci, je comprends mieux l'intérêt des design pattern.
Merci pour ton retour David, objectif de la vidéo réussi alors ! 👍
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 👍)
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.
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.
It was great explanation and great example. Thanks
Thank you for your positive feedback Ekrem !
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.
Super cet exemple de snackbars, on a eu exactement le même problème à mon boulot c'est fou !
Étonnant ! 😅
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.
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 RUclips 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.
Très intéressant, tu expliques mieux l'utilisation des designs pattern
Merci ! 🔥
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 ! 🔥
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