Bonjour, merci pour cette vidéo, je suis en étude d'informatique et on a vaguement expliqué les designs pattern, mais cette vidéo et la précédente m'ont vraiment permis de comprendre l'importance de ces design pattern et comment l'un d'entre eux fonctionne de manière concrète.
Incredible ! Merci beaucoup, le fait d'avoir le details des types de factory rend l'explication du design pattern totalement limpide. 👍 ! Vraiment très très très bien expliqué . On maintenant je ne l'utilise plus par "instinct", je l'utilise en comprenant le pourquoi du comment ! 10/10
Excellent, merci, comme d'habitude. C'est d'une très grande utilité pour les développeurs qui ne bossent pas forcément dans des grosses boites mais avec le désir de s'approcher des conventions, usages, good practices des pros travaillant dans ces entreprises. Les questions que tu t'es posées sont celles que nous nous sommes tous posés à un moment donné.
Une petite réflexion d'ailleurs : le if/else sont peut-être la première logique qu'on apprend en tant que développeur, mais finalement la quasi totalité des questions qui m'ont vraiment permises d'améliorer mon code sont venues de la "haine" des if/else, notamment l'apprentissage des Design Pattern. Un conseil donc aux débutants : apprenez à détester les if/else, cela vous mènera vers des questions hyper intéressantes concernant votre code.
@@jc13OM Pourquoi détester les branchements logiques..? Ca n'a pas de sens ^^' Un branchement logique s'utilise quand il est nécessaire... Parfois, il vaut mieux miser sur l'inférence :-) Mais encore faut-il comprendre quelque chose à la programmation orientée objet, qui se résume finalement à "inverser les dépendances pour un code mieux découpé, plus facilement maintenable et réutilisable"!..
@@psylohzoff4073 J'ai employé un mot fort, mais évidemment que j'utilise des if/else. Mais quand tu débutes, tu as tendance à utiliser ça dans toutes les situations alors qu'il y a des solutions bien plus élégantes, découplées, etc..
Superbe vidéo ! Tu as débloqué ma compréhension des Factory. Je m'entêtais à implémenter le factory pattern dans un projet alors que j'avais besoin que d'une simple factory. Je n'avais aucune connaissance de cette dernière et l'abstraction de l'exemple d'une factory patern ne matchait pas avec mon application. Donc grosse confusion dans ma tête... Merci d'avoir mis les choses au clair !
Bonjour Simon, Un grand merci pour cette future suite de vidéos sur les designs patterns. J'ai récemment intégré une entreprise et on m'a posé des questions sur ce sujet, lors de mon entretien. Grâce à toi, j'ai su quoi dire. Donc, pour répondre à ta question, je suis très intéressé d'en apprendre plus. Ce format est parfait !
C'est une superbe idée, le youtube francophone ne parle pas assez des design patterns ! Magnifique, vivement la suite, et l'implémentation avec des use cases est super importante. Pas mal aussi avec un ressenti personnel sur son utilisation/difficulté. C'est bien vu aussi le memento, peut-être le mettre à dispo sur github, ou en tout cas facilement récupérable ?
Merci pour cette vidéo très claire qui m'a permis de comprendre enfin à quoi servait ce fichu pattern ! Je suis d'accord avec toi : utiliser un exemple concret est beaucoup plus utile que de montrer un diagramme UML. Une question cependant : Au lieu de créer un niveau d'abstraction supplémentaire et d'ajouter une (ou plusieurs) Factory, tel que BookRandomGiftFactory, pourquoi pas simplement ajouter une méthode statique createRandomGift() à la classe BookFactory ? On pourrait ainsi créer un nouveau Book par Type en utilisant la méthode create(bookType, backenData), ou bien créer un Book random avec createRandomGift(), l'avantage est qu'on utilise qu'une seule classe Factory, et qu'on peut ajouter autant de méthode statique createSpecificLogicBook() que de cas différents de logique de création. Est-ce que ça fait sens ce que je dis ?
Dans la classe BookFactory, n'y a-t-il pas une petite coquille dans le switch ? Cela devrait être switch(bookType) au lieu de switch(typeType), non? Merci pour la vidéo...👍
Cool, mais quels sont les design pattern à apprendre quand on utilise Angular ? Il y le singleton pour l'injection des dépendences (les services). Quels autres design patterns devrait-on apprendre ?
Alors j'ai tout compris mais j'ai un blocage : je ne vois toujours pas l'apport d'implémenter cette classe abstraite.... Vu qu'on ne l'utilise pas directement, et étant donné qu'elle ne permet pas de choisir entre les deux classes, pourquoi la créer ? Dans ton code de fin (concernant les book gift) je ne vois pas la différence qu'il y aurait si tu n'avais pas fait cette abstraction....Le code serait identique non ?
Voici pourquoi j’adore utiliser une classe abstraite dans le Factory Pattern : 1. Flexibilité Incroyable : Avec une classe abstraite, je peux définir un canevas pour mes objets et laisser les sous-classes s’occuper des détails. Ça me permet de changer les types d’objets que je produis sans toucher au reste de mon code. 2. Tout est Cohérent : Une classe abstraite assure que toutes mes sous-classes suivent la même structure. Ça rend mon code plus solide et fiable. 3. Facile à Maintenir : Si je dois changer quelque chose, je le fais dans ma classe abstraite et toutes mes sous-classes en profitent. Mon code est plus simple à gérer et à faire évoluer.
@@codeursenior Merci pour ta réponse. 1) Ok je comprends 2) Ça j'avais bien compris c'est même selon moi l'utilité première j'avais cru comprendre que c'était fait pour cela uniquement de base. 3) Alors c'est là que je dois bloquer : on écris du code dans une classe abstraite ? Je n'ai toujours vu que des exemples descriptif jamais avec du code à l'intérieur (même dans les exemples que tu donnes il n'y a pas de code il me semble)
@@GoogleAccount-tc3zd Hello, il est effectivement possible d'écrire du code concret dans une classe abstraite, qui sera utilisé par les classes enfants uniquement.
Tu as oublié le principal, je crois... "A quoi ça sert, concrètement?" Le pattern Factory permet de découpler le code de sa dépendance à l'implémentation de la factory et ainsi d'injecter cette dépendance via une interface et ainsi utiliser la factory de façon transparente sans qu'on ait besoin de savoir de quelle factory il s'agit! Ca permet donc de rajouter des factories au besoin... D'où le fait qu'il faut toujours utiliser Factory, même si ça ne semble pas nécessaire sur le moment, dès lors qu'on estime qu'il est possible que la logique de génération d'une hiérarchie d'objets pourrait évoluer à l'avenir :-3
J'ai appris tellement de chose avec cette vidéo! En pratiquant un peu à coté pour rendre ça ludique
Génial tu m’as cramé la carte mère de mon cerveau c’était génial
Au top, c'est le métier qui rentre !
Bonjour, merci pour cette vidéo, je suis en étude d'informatique et on a vaguement expliqué les designs pattern, mais cette vidéo et la précédente m'ont vraiment permis de comprendre l'importance de ces design pattern et comment l'un d'entre eux fonctionne de manière concrète.
Merci @Dakuten pour ton retour ! C’est exactement l’objectif de ces vidéos, donc mission accomplie pour le moment.
Bon développement,
Simon.
Salut Simon, très intéressant. Ce n'est pas évidant les explications d'une façon la plus simple possible et compréhensible. Merci
Incredible ! Merci beaucoup, le fait d'avoir le details des types de factory rend l'explication du design pattern totalement limpide. 👍 !
Vraiment très très très bien expliqué . On maintenant je ne l'utilise plus par "instinct", je l'utilise en comprenant le pourquoi du comment ! 10/10
Excellent, merci, comme d'habitude. C'est d'une très grande utilité pour les développeurs qui ne bossent pas forcément dans des grosses boites mais avec le désir de s'approcher des conventions, usages, good practices des pros travaillant dans ces entreprises.
Les questions que tu t'es posées sont celles que nous nous sommes tous posés à un moment donné.
Une petite réflexion d'ailleurs : le if/else sont peut-être la première logique qu'on apprend en tant que développeur, mais finalement la quasi totalité des questions qui m'ont vraiment permises d'améliorer mon code sont venues de la "haine" des if/else, notamment l'apprentissage des Design Pattern.
Un conseil donc aux débutants : apprenez à détester les if/else, cela vous mènera vers des questions hyper intéressantes concernant votre code.
@@jc13OM Pourquoi détester les branchements logiques..? Ca n'a pas de sens ^^' Un branchement logique s'utilise quand il est nécessaire... Parfois, il vaut mieux miser sur l'inférence :-) Mais encore faut-il comprendre quelque chose à la programmation orientée objet, qui se résume finalement à "inverser les dépendances pour un code mieux découpé, plus facilement maintenable et réutilisable"!..
@@psylohzoff4073 J'ai employé un mot fort, mais évidemment que j'utilise des if/else. Mais quand tu débutes, tu as tendance à utiliser ça dans toutes les situations alors qu'il y a des solutions bien plus élégantes, découplées, etc..
Superbe vidéo ! Tu as débloqué ma compréhension des Factory.
Je m'entêtais à implémenter le factory pattern dans un projet alors que j'avais besoin que d'une simple factory. Je n'avais aucune connaissance de cette dernière et l'abstraction de l'exemple d'une factory patern ne matchait pas avec mon application. Donc grosse confusion dans ma tête...
Merci d'avoir mis les choses au clair !
Merci Simon, toujours très clair.
ta chaine donne envie de se reconvertir dans Angular !
Continues comme ça tu vas vite percer
Merci Thomas pour ton message ! On lache rien 😉
Bon développement,
Simon.
Super ce pattern et Super bien expliqué ! Merci pour ton partage 👍
Hâte de sauvegarder toute la playlist DP, et hâte des futurs interview dev seniors. :)
Très bonne idée de vidéos !!! J’attendais avec impatience une version française des vidéos du UA-camur que tu as cité
Super, comme dit plus bas le youtube francophone est en carence de sujet concernant les design pattern !
Merci pour le travail que tu fait 👌
Au Top! Encore une fois des explications claire. Reste plus qu'à pratiquer :) . Merci Simon !
Merci pour le feedback, content que ça te plaise !
Bon développement à toi,
Simon.
Merci beaucoup Simon, très intéressant et enrichissant 👍😎
Merci, content que ça te plaise !
Bon développement à toi,
Simon.
Bonjour Simon,
Un grand merci pour cette future suite de vidéos sur les designs patterns.
J'ai récemment intégré une entreprise et on m'a posé des questions sur ce sujet, lors de mon entretien.
Grâce à toi, j'ai su quoi dire.
Donc, pour répondre à ta question, je suis très intéressé d'en apprendre plus. Ce format est parfait !
👍toujours des bonnes explications, merci !
Merci pour ton retour Jérémy !
C'est une superbe idée, le youtube francophone ne parle pas assez des design patterns ! Magnifique, vivement la suite, et l'implémentation avec des use cases est super importante. Pas mal aussi avec un ressenti personnel sur son utilisation/difficulté. C'est bien vu aussi le memento, peut-être le mettre à dispo sur github, ou en tout cas facilement récupérable ?
Perso c'est pas que ca m'intéresse "quand même" mais ça m'intéresse SURTOUT ce genre de vidéo technique !
Merci pour tes explications et ta clarté :)
Merci beaucoup, tjs aussi enrichissant !
Merci pour ton retour @Sqls !
Super je l'attendais celle là
Merci, j'espère que ça vous a plu !
Bon développement,
Simon.
@@codeursenior bien-sûr j'espère que tu feras plus de vidéo sur le sujet
@@rs4267 Oui j'ai prévu de faire les 23. Reste à planifier tout ça pour les prochains mois. 👍
@@codeursenior Merci pour tout ce que tu fais, j'ai beaucoup de chance de pouvoir suivre tes cours prof
Excellente vidéo. Tu pense poster les vidéos sur les design pattern tous les combien ?
Merci!🎉
Avec plaisir. Bon code à vous !
Merci pour cette vidéo très claire qui m'a permis de comprendre enfin à quoi servait ce fichu pattern !
Je suis d'accord avec toi : utiliser un exemple concret est beaucoup plus utile que de montrer un diagramme UML.
Une question cependant : Au lieu de créer un niveau d'abstraction supplémentaire et d'ajouter une (ou plusieurs) Factory, tel que BookRandomGiftFactory, pourquoi pas simplement ajouter une méthode statique createRandomGift() à la classe BookFactory ?
On pourrait ainsi créer un nouveau Book par Type en utilisant la méthode create(bookType, backenData), ou bien créer un Book random avec createRandomGift(), l'avantage est qu'on utilise qu'une seule classe Factory, et qu'on peut ajouter autant de méthode statique createSpecificLogicBook() que de cas différents de logique de création.
Est-ce que ça fait sens ce que je dis ?
Très intéressant. Je me demande si on peut appliquer la même logique sur les problématiques de manipulation du dom.
Factory = Logique de création. Pour la manipulation du DOM, je n'ai rien qui me vient en tête.
Merci
👍
Dans la classe BookFactory, n'y a-t-il pas une petite coquille dans le switch ? Cela devrait être switch(bookType) au lieu de switch(typeType), non?
Merci pour la vidéo...👍
Cool, mais quels sont les design pattern à apprendre quand on utilise Angular ? Il y le singleton pour l'injection des dépendences (les services). Quels autres design patterns devrait-on apprendre ?
Alors j'ai tout compris mais j'ai un blocage : je ne vois toujours pas l'apport d'implémenter cette classe abstraite.... Vu qu'on ne l'utilise pas directement, et étant donné qu'elle ne permet pas de choisir entre les deux classes, pourquoi la créer ? Dans ton code de fin (concernant les book gift) je ne vois pas la différence qu'il y aurait si tu n'avais pas fait cette abstraction....Le code serait identique non ?
Voici pourquoi j’adore utiliser une classe abstraite dans le Factory Pattern :
1. Flexibilité Incroyable : Avec une classe abstraite, je peux définir un canevas pour mes objets et laisser les sous-classes s’occuper des détails. Ça me permet de changer les types d’objets que je produis sans toucher au reste de mon code.
2. Tout est Cohérent : Une classe abstraite assure que toutes mes sous-classes suivent la même structure. Ça rend mon code plus solide et fiable.
3. Facile à Maintenir : Si je dois changer quelque chose, je le fais dans ma classe abstraite et toutes mes sous-classes en profitent. Mon code est plus simple à gérer et à faire évoluer.
@@codeursenior Merci pour ta réponse.
1) Ok je comprends
2) Ça j'avais bien compris c'est même selon moi l'utilité première j'avais cru comprendre que c'était fait pour cela uniquement de base.
3) Alors c'est là que je dois bloquer : on écris du code dans une classe abstraite ? Je n'ai toujours vu que des exemples descriptif jamais avec du code à l'intérieur (même dans les exemples que tu donnes il n'y a pas de code il me semble)
@@GoogleAccount-tc3zd Hello, il est effectivement possible d'écrire du code concret dans une classe abstraite, qui sera utilisé par les classes enfants uniquement.
Tu as oublié le principal, je crois... "A quoi ça sert, concrètement?"
Le pattern Factory permet de découpler le code de sa dépendance à l'implémentation de la factory et ainsi d'injecter cette dépendance via une interface et ainsi utiliser la factory de façon transparente sans qu'on ait besoin de savoir de quelle factory il s'agit! Ca permet donc de rajouter des factories au besoin... D'où le fait qu'il faut toujours utiliser Factory, même si ça ne semble pas nécessaire sur le moment, dès lors qu'on estime qu'il est possible que la logique de génération d'une hiérarchie d'objets pourrait évoluer à l'avenir :-3
Factoryception 😅
Gang of Four ?
Yep, tout à fait.
@@codeursenior je me suis renseigné entre temps, j'assimile les concepts. Merci !
@@poischiche2933 🚀
DesignPattern.context( data ).create(); // Superbe vidéo
Au top merci !