Comment résoudre un problème de code difficile avec les Design Patterns ?

👨🏻‍💻 Démarrer votre carrière de Développeur Professionnel :
www.angularsenior.fr/apply
***
Je vais vous montrer une exigence réelle que j’ai eue d’un client.
Vous allez tout de suite vous rendre compte de l’abîme qu’il y a entre les tutoriels... et ce qui vous attend dans la vraie vie.
Restez bien jusqu’au bout pour comprendre comment j’ai résolu cette exigence de code très difficile...
(Et surtout les erreurs que j’ai pu faire pendant ce parcours.)
Bon visionnage,
Simon.
***
00:00 : Introduction
00:13 : Présentation de l'exigence du client
01:06 : Les 3 défauts de la solution "brute-force" initiale
03:28 : Comment trouver une solution viable à un problème de code difficile ?
04:22 : Les 4 cas d'utilisations du Decorator Pattern
06:41 : Les 5 types de décorateurs
08:52 : Comprendre le "Hello, World !" du Decorator Pattern
11:58 : Le décorateur @Track du Codeur Senior
14:51 : Conclusion

[@TarjaxCraft]

Assez fervent de ce type de vidéo où tu nous donnes un problème complexe concret avec tes explications pour le résoudre. Je ne sais pas ce qu'en pensent les autres mais, je ne serais pas déçu de revoir ce type de contenue 😉

[@codeursenior]

Hello, c'est noté, en plus c'est intéressant de faire une rétrospective de ses choix techniques. Je me note de partager mes prochains défis techniques avec vous !

[@arnoldkienou42]

merci pour le temps que tu accorde pour nous instruire, Simon !

[@LeWebMaster228]

Je deviens de plus en plus addict a tes contenus, merci Mr Dieny

[@alexismathey1890]

Super intéressant ! Merci pour le partage !

[@DavidRENAUD-ss5yj]

Merci Simon, encore une bonne vidéo et belle découverte des "Decorator pattern". A bientôt pour la prochaine vidéo 👌 David.

[@kemosdraec]

Merci! J'ai trouvé cela extrêmement instructif!

[@MrZen42]

Bravo, c'est hyper clair, je suis vraiment très debutant et j'avoue que ton contenu me semble plutot facile à s'approprier.

[@LudovicKUHN]

Très intéressant, merci du retour

[@codeursenior]

Merci à toi, bon code.

[@maxwebstudio]

Super interessant! Merci

[@stephane6730]

Un pepite la vidéo comme a chaque fois. Merci

[@codeursenior]

Grand merci pour ce commentaire, très motivant. Bon code à toi !

[@YouDJeuR]

Merci pour ton partage de raisonnement.

[@abasop5946]

merci Simon c'est super instructif

[@codeursenior]

Au top, merci pour retour et bon code.

[@guillaumest1]

Passionnant et inspirant ! Beau boulot 👍

[@zack9553]

Tu as raison 😉

[@toofitoutflemme]

merci beaucoup pour l'illustration de ce design pattern!

[@codeursenior]

Avec plaisir, content que les explications soient claires. Bon code !

[@fabricehategekimana5350]

Encore une fois, une vidéo de qualité! 13:27 Dans mon cas j'ai plus l'habitude de remplacer une classe munie d'une méthode par une fonction contenant une structure. C'est en général plus léger. Encore une fois merci pour toute la valeur ajoutée dans le developpement. J'ai beaucoup appris depuis que je suis cette chaîne

[@codeursenior]

Hello, merci pour votre partage utile. Votre suggestion est pertinente effectivement. Dans mon cas j’avais suffisamment de traitement en plus que ce que je présente dans la vidéo, pour justifier l’utilisation d’une classe (il me semble en tout cas). Bon code à vous et à bientôt pour de prochaines vidéos !

[@aniskadri140]

Excellent !

[@codeursenior]

Merci !

[@krissclotilde8857]

Excellent ❤

[@codeursenior]

Merci !

[@iamavegetable1936]

Nickel!

[@louislouis9859]

Salut, ce format est vraiment super interessant, si l'occasion se présente à toi je trouverais ça génial de voir d'autre implémentation de Design Patterns dans des cas concrets. merci pour tes videos.

[@noice784]

up

[@jc13OM]

Ultra instructif, je connaissais le DP Decorator pour les classes, mais pas comme ça. Ca fait un peu penser aux proxy en JS, dans le sens "je rajoute une couche autour de mon objet pour intercepter les appels à ses méthodes, et je rajoute mon comportement".

[@alexandrenicolas4314]

C'est juste du sucre syntaxique pour faire une hof.

[@sitedel]

En java cette utilisation du décorateur correspond à l'ajout d'un aspect. La programmation orientée aspect est utilisée pour gérer tout ce qui relève de l'observation ou du suivi d'une séquence de traitements. C'est notamment le cas des transactions de bases de données, ce qui revient à suivre la séquence des appels pour valider la transaction( commit) si tout s'est bien passé, et annuler si une exception ou une demande de retour arrière (rollback) a eu lieu.

[@IElial]

Je voulais savoir justement si le design pattern Decorator implique forcement de l'AoP ? Comme vous dites "cette utilisation" je me demande si il y a d'autre utilisation du pattern Decorateur qui ne débouchent pas sur de l'AoP ?

[@mabilonchristophe1069]

top tes vidéos 👍

[@codeursenior]

Merci pour ton message Christophe. Bon code à toi, Simon.

[@emmanuelmichonneau6525]

Super explication du decorator pattern !👏 Par contre le contexte de départ me semble être un antipattern. Je m'explique, le front qui poll comme un fou en quête de données fraiches, c'est le signe d'un back mal conçu. Ca serait bien plus propre de faire de l'event driven avec un back qui notifie le front que des nouvelles données sont disponibles. 😉

[@moitp2]

Personnellement, j'aurais opté pour une approche 100% RxJs. Cela permettrait de s'éviter une surcouche via des décorateurs qui complexifie la chose pour les nouveaux arrivants sur un projet legacy. Les opérateurs RxJs permettent également de se débarrasser de pas mal de boilerplate. Maintenant, il est difficile de se rendre compte des impacts (refacto) d'une telle proposition. Il est évoqué "un composant de 1000 lignes" qui fait appel à un service lui-même injecté dans d'autres composants. Ceci dit, il faut aussi voir comment le code est fait, et surtout si les devs sur le projet ont l'habitude de travailler avec du RxJs plus complexe. Maintenant, si on revient au problème initial, pourquoi faire du polling au lieu de passer par une connexion via websocket ? C'est bien moins couteux en ressources côté serveur.

[@Einherjar02]

je me posais la meme question avec websocket.

[@nabsbladeofmiquella2315]

Idem j'ai toute suite penser à des websockets 😅

[@stephenstrange2296]

Web socket - webhook - broker - plein de solutions existe

[@saidmansour9200]

thank you 🙏🙏🙏

[@codeursenior]

🔥

[@RedSnoww12]

Possible d'avoir une vidéo sur la clean archi ? pour un contexte de projet Angular ?

[@DenisZana]

Moi, je ferais tout coté back ... une seule requête vers le serveur ( avec les bons paramètres en entrée) , le back se charge de tester s'il y a lieu de lancer d'autres requêtes complémentaires ( vous dîtes plus de 5 ?) Et retourne un résultat voulu, et surtout les infos des requêtes qu'il a du faire, pour que le front soit au courant) ... Sinon , vous allez faire une usine à gaz , et ralentir votre font , a chaque requête une attente , et donc au pire vous allez avoir un timeout de rejet . Pour moi , c'est une erreur général des dév front , ils veulent tout faire coté front , en oubliant la latence du réseau ... J'ai déjà eu ce problème, où l'on devait vérifier une par une les cellules d'un fichier excel envoyé au serveur , et le dev avait développé son code front , pour que chaque cellule soit vérifié une par une par le front , avec autant de requêtes que de cellules , et bien sûr avec de gros tableaux Excel, et des milliers de requêtes , même en async rone, évidement timeout ... ( design pattern ? Sur le web, moi cela m'a toujours paru débile, mais bon , sans doute , j'y connais rien , avec mes 20 ans d'expérience , et sans doute , mes vieilles utilisations du procédurale d'autant, désolé , il n'y a pas qu'une seule solution )

[@soverain]

Je pense que l’exemple donné ici pour l’utilisation découle d’une contrainte inflexible : on ne peut pas tout recoder, il faut adapter la solution actuelle. Évidement dans un monde ideal tout cela devrait se passer coté serveur et éventuellement en websocket. Mais la réalité c’est qu’on doit souvent enrichir l’existant, qui a parfois été codé il y a longtemps et avec d’autres contraintes. Je trouve que la solution proposée ici est parfaitement adaptée. La complexité est abstraite et cloisonnée dans le décorateur. Les jeunes développeurs n’ont pas besoin d’y mettre leur nez pour avoir une idée de ce que cette ligne de code fait. C’est pas un problème d’être vieux ou jeune, d’avoir une ou vingt années d’expérience. Le problème c’est comment s’adapter a un contexte, a une base de code existante sans avoir la possibilité de tout recoder. Quant aux design pattern sur le web, il sont deja présents partout dans les frameworks moderne. C’est inévitable quand on voit l’évolution massive de la complexité des applications web d’aujourd’hui. Le front d’aujourd’hui c’est le back d’antan, que ca plaise ou non.

[@dzdzqdzaqd]

C'est un peu comme un Hook en React non? Dis moi si je dis des bêtises haha En tout cas super vidéo comme d'habitude 😁

[@pH7Programming]

Très chouette retour d'expérience Simon👌+1 pour le decorator pattern 👍 Est-ce que l'utilisation des WebSockets pour que le serveur puisse signaler le client les nouvelles données arrivées n'auraient-elle pas pu faciliter ton problème en question ?

[@codeursenior]

Hello, effectivement vous êtes plusieurs à avoir mentionner l’utilisation des websockets plutôt que du pulling. Malheureusement dans notre cas ce n’étais pas possible d’apporter cette modification côté backend. Bon code, Simon.

[@angelHighTech]

Pourquoi ne pas avoir utilisé les websocket ? Et faire un filtre dans le backend ...

[@Gatsu351]

Vous avez pensé à faire de SSE (Server Side Event) au lieu de poll ?

[@houssemghazala]

C'est l'enfer

[@Gatsu351]

@@houssemghazala ah et pourquoi donc ?

[@magrigrigri]

Si ce sont des données stockées dans une BDD par exemple, au final c’est le back qui va faire du pooling auprès de la base de données. A moins de créer une sorte de queue et ajouter un élément dans la queue à chaque fois que la donnée est MAJ, ce qui complexifie quand même considérablement la stack si on a pas déjà ce qu’il faut.

[@Mohamed-uf5jh]

Salut Simon ! et oui c est la programmation orientée aspect ( AOP) que les framerworks digne de ce nom utlisent . Merci

[@codeursenior]

Tout à fait, le nom est impressionnant, mais c’est une corde utile à avoir à son arc. Bon code, Simon.

[@is-sam]

J'ai implémenté la même chose (à peu prêt) dans un Interceptor, comme j'avais besoin de track toutes les requêtes

[@codeursenior]

Hello, merci pour la suggestion. J’ai tendance à préférer éviter le mix de scope. Un intercepteur est globale, la tracking est local au composant. En regardant le code, je ne peux pas savoir si le composant est tracké ou non. Je demande donc aux gens de sauvegarder cette information dans leur tête.

[@TheBlackManMythLegend]

jai decouvert au moment de la description qu'il fallait utiliser un decorateur et pourtant je n'ai pas lu ce livre. juste l'experience.

[@morgannavel4552]

En ce moment à la fac, je commence à beaucoup entendre parler de design pattern, j'en ai encore jamais utilisé ou du moins pas explicitement je pense. Je comprends bien les design pattern, mais je trouve ça assez dur de ce dire "Ah mais je dois faire le design pattern machin pour y arriver !". Je pense que ça viendra avec l'expérience surement...

[@ChaotikmindSrc]

Oui ben justement ne fait pas ca, c'est un piège à con !

[@abdoulhamidcoulibaly2385]

Dans un projet, tu vas devoir utiliser sûrement plusieurs designs patterns ensemble pour aboutir à quelque chose de propre.

[@loisnzothiam7489]

programmation par aspect!

[@arnaud-bondaz]

Le level

[@seroltech118]

Tout cela n'aurait pas pu être évité en utilisant des socket au lieu du système pooling ??

[@placedelechange]

Socket sur des services third party.......

[@placedelechange]

J'aurais fais un truc simple et léger avec une petite pollution du proto XHR pour récupérer les calls (debounce + log inclus), ensuite remplir une Array(funcUrl1, funcUrl2) avec des function attribuée par les call que j'itere tout les 15 sec , le tout bien commenté et clean pour le maintien.. La c'est juste super crade l'approche en ts, les décorateurs sont pas perf du tout avec des apply() et des spreads à tout va ... Lourd, lent et illisible, l'observable est gadget.

[@zHqqrdz]

Tout à fait, le cas typique de l'over engeneering qui fait mal (sans parler de l'implémentation du decorator qui fait 20 lignes juste pour l'exemple alors que de base c'est juste une classe qui en surcharge une autre c'est vraiment le pattern le plus simple)

[@benilunga1641]

Il y a le fantasme est la réalité merci pour le conseil

[@Xilrog]

Utiliser du polling en 2023 c est pas permis. Ca m'a pas donner envie de regardé la vidéo après ça, j'ai regardé les chapitres, design pattern decorator euh non par contre observer je dis oui, sinon on peux mettre en place des WebSocket ou des callbacks ça a l'avantage de pas bouffer toutes tes ressources et avoir les maj en temps réel

[@soufianeg3815]

C’est un « problème de code difficile ». Pute à clicks 🥹

[@oliviera.6850]

Et dieux créa les websockets ...

[@codeursenior]

... mais le client n'aimait pas Dieu.

[@cheikhna1947]

Le mec bosse probablement pour une bank ou une assurance . Il n"y a que eux qui ont 36 000 requetes et 73000 APIs pour un seul feature 😂😂😂 Pour toutes les équipes backend adeptes de la secte micro services, faites du bruit silvousplait !! 😂

[@denisjean-bastien1253]

Oui ça semble être un patch d'un problème nommé "historique" xD Le mieux serait d'assainir le backend pour qu'il rende service au front et non complexifier le front pour convenir au backend "historique" (ou "prehistorique 😂). Apres on a pas le contexte, c'est peut-être légitime 😅

[@legendary4226]

mouai, pas convaincu de "penser comme les meilleurs" Je dirais plus qu'il faut en premier identifier les bouts de codes impacté (ici les fonctions qui ont besoins de tracking) et ensuite essayer de trouver une solution au même niveau d'abstraction. Si on voit que ça part un peu dans le chaos des IF ELSE, monter d'un cran en abstraction.

[@codeursenior]

Je n’ai pas compris la porté de votre commentaire. Qu’entendez vous par tracker les requêtes d’un composant « au même niveau d’abstraction ». Si vous avez un exemple de code je suis preneur.

[@legendary4226]

@@codeursenior Quand je dis "même niveau d'abstraction" c'est que le "code de base" je le considère comme le niveau 1 d'abstraction par exemple. Les interfaces le niveau 2, les fonctions le niveau 0, etc. Bien sûr je n'ai pas d'échelle d'abstraction en tête (avant les fonctions il y a l'assembleur, les portes logiques). C'est compliqué à expliqué comme l'abstraction est une notion que je ne sais pas encore exploiter à son plein potentiel. Ce que je veux dire c'est que quand on retrace le cheminement entre les portes logiques gravées dans un processeur jusqu'au code que l'on produit aujourd'hui, on voit un schéma se répéter : on exploite le "niveau" au maximum et on se trouve bloquer, alors on monte un cran dans l'abstraction pour indirectement résoudre le problème. Et justement quand je dis "résoudre indirectement" c'est tout là la question : "pourquoi est-t-on amené à abstraire les concepts ?" Je n'ai pas de code à montrer, simplement on voit ici que résoudre ce problème en utilisant l'abstraction simplifie le code. Ce que je veux dire c'est que, la vidéo n'explique pas vraiment comment "penser comme les meilleurs". Et j'ai essayé de mettre des mots sur ce qui nous amène à franchir un niveau d'abstraction. Et surtout ce qui n'est pas dit c'est que, il existe forcément une façon de résoudre le problème au même niveau d'abstraction. La réponse à ma question plus haut, du moins ce que je pense à mon niveau de BAC +2/+3, on n'est pas fait pour à la fois penser compliqué tout en respectant les principes de code propre, maintenable etc. Parce que c'est une énorme équation qu'on essaye de résoudre et en cours on nous apprend pas à réfléchir "abstraction", mais on nous apprend à utiliser l'abstraction. Ce qui est une grosse erreur (et j'en suis convaincu alors que je n'ai que effleuré du doigt la puissance de cette notion), il faut savoir façonner l'abstraction comme bon nous semble et non en apprendre l'utilité. Car même si l'on comprend son fonctionnement, ses avantages et inconvénients, ça n'empêche que ça ne nous rend pas capable de créer nous même des "design patterns". Et c'est un enjeu aujourd'hui je pense.

[@codeursenior]

@@legendary4226 Votre commentaire me paraît abstrait, désolé.

[@zHqqrdz]

​@@codeursenior Son commentaire est tout ce qu'il y a de plus concret. Tu parles dans ta vidéo de comment utiliser l'abstraction (le design pattern) plutôt que de comment la découvrir. Les design patterns, d'ailleurs, ne sont pas censés être appliqués "comme ça". Il faut les comprendre, et ensuite les "découvrir" dans le contexte de notre code (ceci est écrit dans le livre que tu cites). Dire "comment feraient les meilleurs" ça n'apporte malheureusement rien de + que de dire "utilise google". Il serait bien + intéressant de comprendre la problématique, imaginer des solutions abstraites et chercher des implémentations concrètes ensuite. Le decorator pattern se serait imposé s'il était réellement la meilleure solution, comme potentiellement d'autres solutions (comme, au hasard, simplement modifier la config de xhr/fetch ou l'interface que vous utilisez pour faire vos requêtes). J'imagine que vous avez analysé les perfs ? Parce que je pense qu'avoir autant de décorateurs ça va faire très très mal si le composant fait 1000+ lignes et que vous faites autant de requêtes.

[@codeursenior]

@@zHqqrdz Ok j'ai mis un peu de temps mais j'ai fini par comprendre ce que vous entendez par "Comment découvrir" vs "Comment utiliser". Vous trouvez que la vidéo est trop accès sur l'implémentation plutôt que sur comment découvrir comment on en a besoin dans son code (partie "découvrir") ? Concernant "s'inspirer des meilleurs", je reste sur ma position. C'est la seule chose que je fait toute la journée : lire, s'intéresser, regarder comment font les meilleurs dans notre domaine. Pour Angular je m'intéresse aux travaux de John Papa, Manfred Steyer et Alain Chautard.

[@sparttan21]

vive graphql, c'est beaucoup plus simple pour faire ça

[@codeursenior]

Hello, je n'ai jamais utilisé GraphQL en production. Il y a une feature pour tracker des requêtes comme ça ?

[@sparttan21]

​@@codeursenior pardon, je me suis planté de vidéo je crois xD Ou peut être pas. j'ai oublié le contexte. En GraphQL c'est ton composant root qui charge les données. Tu fais des fragments dans les sous composants ce qui permet d'avoir le typage de données spécifique au composant dans chacun d'eux. Ça n'empêche pas de pouvoir faire d'autres appel dans les sub components. T'as une requête "GET" (même si tout est fait en POST) pour récup tes données qui récupère que ce qui est nécessaire. Tu peux avoir plusieurs mutations pour modifier tes données. Avec Apollo et Relay (les 2 principaux clients) tu peux refresh juste les composants dont les données ont changé après une mutation, ou un call asynchrone au besoin Je trouve ça tellement plus simple à utiliser, les données sont nommées et structurées proche du language naturel. C'est donc plus simple pour rentrer dans une API et comprendre sa structure Après, ça fait très longtemps que je n'ai pas fait du REST, donc je ne suis plus trop objectif sur le sujet ^^

[@codeursenior]

@@sparttan21 Merci pour le retour, j'espère avoir l'occasion d'utiliser ça prochainement.

[@sparttan21]

@@codeursenior par contre, ça marche que si tu l'as d'origine. C'est bien sûr possible de migrer de rest vers graphql. Voir même d'avoir ton api rest entre ton back-end et ton api graphql. J'ai vu ça dans une conf.

[@codeursenior]

@@sparttan21Ok, merci pour la précision. Bon code.