Це відео не доступне.
Перепрошуємо.
Maîtrisez les principes SOLID : C’est la seule façon d’écrire du code propre !
Вставка
- Опубліковано 18 сер 2024
- 👨🏻💻 Démarrer votre carrière de Développeur Professionnel :
www.angularsen...
***
Aujourd'hui, on va transformer votre manière de coder avec Angular en utilisant les 5 principes SOLID.
Je vais vous montrer comment ces cinq principes peuvent rendre votre code plus propre, plus efficace, et vous faire gagner un temps fou. Il vous faut les 5 car ils sont tous reliés et marchent entre eux pour maximiser le résultat !
Bon visionnage,
Simon.
***
00:00 : Introduction
03:35 : Single Responsability Principle (SRP)
09:42 : Open-Closed Principle (OCP)
13:29 : Liskov Substitution Principle (LSP)
15:27 : Interface Segregation Principle (ISP)
17:50 : Dependency Inversion Principle (DIP)
20:59 : Résumé sur feuille A4
Excellente vidéo, merci beaucoup pour tes explications.
Merci à toi pour le retour. Bon code !
Très bonne vidéo, en complément et/ou en ajout, je pense qu'une explication concernant les architectures n-Tiers et les différentes couches qu'on retrouve généralement dans serait géniale. Même, si il y'a d'autres architectures possibles, le n-Tiers reste une très bonne base et une bonne application des principes SOLID.
Petite précision pour OCP, l'acronyme prête a confusion: Open-closed principle, pour bien le comprendre, il faut le voir sous cette angle : open for extension, but closed for modification. En claire: On peut étendre une classe mais pas la modifier. Un exemple de ce principe est le design paterne des Observer chez Rx, Lior Chamla explique très bien le OCP dans sa série sur Rxjs
En programmation orientée objet, le principe ouvert/fermé (open/closed principle) affirme qu'une classe doit être à la fois ouverte (à l'extension) et fermée (à la modification). Il correspond au « O » de l'acronyme SOLID. « Ouverte » signifie qu'elle a la capacité d'être étendue. « Fermée » signifie qu'elle ne peut être modifiée que par extension, sans modification de son code source.
L'exemple utilisé pour l'OCP me parait bancal, car outre le volume de code final démultiplié (donc, plus il y a de ligne, moins c'est maintenable... à contrario du KISS), ca n'élude pas qu'un moment donné il faut faire un découpage par type pour utiliser la bonne stratégie, là où il fallait déterminer le bon calcul: on ne fait que déplacer le pb...
Super le rappel SOLID très bien expliqué. :)
Mais il ne faut pas oublier qu'une architecture parfaite est une archi qui répond aux problématiques et à la complexité d'une app à un instant T. Un surdécoupage pour un composant qui fait 100 lignes de code, parce qu'on veut qu'il soit SOLID, c'est souvent une aberration qui créé plus de mal que de bien. Il faut partir du principe que le refactoring fait partie intégrante de l'évolution du code.
Ainsi, on évite les middleman inutiles, les interfaces en trop, bref on reste vraiment YAGNI et KISS (qui sont 2 acronymes qui imho peuvent s'utiliser à toutes les sauces. :) )
Une archi, c'est un peu comme un organisme vivant en fait.
C’est Madame Mac Michu, ta prof d’anglais au collège. Attention, a-t-on dit dr[i]ven and not dr[aï]ven 😉. Merci pour cette piqûre de rappel !.
Madame Mac Michu😂
Merci de suivre vos élèves
@@louqmaneinoussa6649 Madame Mac Michiouuu 😉
@@Khalid15325 autant pour moi 🌚
@@louqmaneinoussa6649 No problem 😉
Je vous aime madame Mac Michou, vous êtes trop chou 😅😅
Vous m'avez manquez coach j'espere que vous allez super, bon retour parmi nous
Merci beaucoup, super bien expliqué avec des exemples assez concret et des petits tips en plus (Le vert sur les PR) !
Très instructif, merci!
Explications très utiles et vraiment accessibles. Merci ! Tu qs vraiment une très bonne pédagogie !
Merci beaucoup pour cette vidéo ! Tu expliques super bien !
Excellent comme d'habitude, merci!
C'est très intéressant, mais j'ai un peu l'impression que c'est 50 nuances de "il faut fragmenter son code" avec plus ou moins toujours le même argument : "comme ça quand ca pète, il n'y a qu'un petit fragment qui pète". Alors c'est pas nul, je sais que je fragmente moi même pas assez mes codes, juste que c'est plus un seul grand principes avec 5 cas généraux typiques ou ce principes s'applique plutôt que 5 grands principes.
D’un point de vue novice, cela peut ressembler à ca. L’expérience dans le domaine permet d’approfondir sa réflexion la dessus :
Les principes SOLID sont bien plus qu’une simple fragmentation du code. Ils fournissent un cadre pour concevoir des logiciels robustes, maintenables et évolutifs. Chaque principe a une intention et une justification spécifiques. Expliquons-les un par un pour illustrer pourquoi ils ne se limitent pas à “fragmenter son code”:
1. S - Single Responsibility Principle (SRP):
• Intention: Une classe devrait avoir une seule raison de changer.
• Justification: En veillant à ce que chaque classe ait une seule responsabilité, nous facilitons la maintenance et la compréhension du code. Cela ne signifie pas simplement diviser le code, mais s’assurer que chaque division a un objectif clair.
2. O - Open/Closed Principle (OCP):
• Intention: Les logiciels doivent être ouverts à l’extension, mais fermés à la modification.
• Justification: Ce principe nous encourage à penser à l’extensibilité. Au lieu de modifier constamment le code existant (ce qui peut introduire des erreurs), nous devrions pouvoir étendre les comportements existants de manière modulaire.
3. L - Liskov Substitution Principle (LSP):
• Intention: Les objets d’une classe dérivée doivent pouvoir remplacer ceux d’une classe de base sans affecter la correction du programme.
• Justification: Il ne s’agit pas seulement de fragmentation, mais de s’assurer que les sous-classes maintiennent la véritable essence ou le contrat de la classe de base.
4. I - Interface Segregation Principle (ISP):
• Intention: Les clients ne devraient pas être forcés de dépendre des interfaces qu’ils n’utilisent pas.
• Justification: Cela évite d’avoir des interfaces “monolithiques” ou “tout-en-un” qui peuvent être encombrantes ou non intuitives pour les clients. Cela favorise la clarté et la pertinence des interfaces pour chaque client.
5. D - Dependency Inversion Principle (DIP):
• Intention: Les modules de haut niveau ne devraient pas dépendre des modules de bas niveau. Les deux devraient dépendre des abstractions.
• Justification: Ce principe favorise l’inversion du contrôle et la dépendance sur des abstractions, non sur des détails concrets. Il guide la structure du code pour qu’elle soit moins fragile face aux changements et plus modulaire.
En somme, les principes SOLID ne sont pas simplement des règles pour diviser le code. Ils représentent une philosophie de conception logicielle qui encourage la cohésion, la découplage, et la modularité, tout en mettant l’accent sur la création d’un code maintenable et évolutif.
Merci pour ces explications concises et de qualité.
Merci à toi pour ton retour !
Bon code,
Simon.
Bonjour et merci pour ces explications ! Est-il possible de nous mettre à disposition la feuille de synthèse finale ? Merci d'avance !
C'est exactement ce que j'allais demander, même en 1080p la feuille A4 n'est pas très lisible, un petit PDF ça serait parfait !
Merci pour la vidéo !
Merci Simon pour ces explications claires (comme d'hab !)
Tellement enrichissant !!
Content que vous ayez pu vous enrichir ! 💰 j’espère que c’est légal !
Hello superbe vidéo ! Bravo pour ton travail il apporte de la VA pour beaucoup je pense ! Je crois comprendre certains des principes grâce à toi et je t’avoue que j’ai du mal à comprendre comment organiser un projet en terme de dossier et où placer les différents fichiers. Ce serait super d’avoir une vidéo là dessus ou bien un simple lien vers un screenshot me suffirait amplement ! Penses tu pouvoir réaliser mon souhait ? A bientôt !
Petite remarque vis à vis de la solution que tu proposes pour la violation de Liskov, à la base si on voulait que carré hérite de rectangle, c'était pour partager une partie du code avec rectangle, faire hériter les deux de shape corrige certe la violation de liskov mais on perd ce qu'on cherchait à faire au passage, qui est faisable en partie si on définit la relation entre des interface en lecture seule de carré et de rectangle (càd des interfaces qui n'exposent que les get pour width / height)
Bonjour, merci pour votre retour. Ce n'est pas possible de le faire au niveau de Shape ?
@@codeursenior je ne pense pas car si, avec square héritant de rect, on avait une hypothétique fonction area(rect) = rect.width * rect.height, on pouvait, comme attendu, utiliser area pour square, mais si (après la refacto introduisant shape), on réécrit area pour qu'elle prenne shape en argument on se retrouve avec un résultat erroné pour area(circle) par exemple, et si on ne récrit pas area et qu'elle garde rect en argument, on ne peut plus l'utiliser pour square (qui était le genre de choses qu'on souhaitait pouvoir faire en faisant hériter square de rectangle au départ)
Merci pour cette explication 👍
excellent sujet, merci 👍
Super intéressant merci pour ta vidéo
Avec plaisir, bon code à vous.
Simon.
Tu laisses pas assez longtemps le code à l'image
la barre espace c'est pas mal mdr
@@hydrogen6110 j'ai plus les explications après
Sur pause. Tu lis et assimile le code et réécoute l'explication
Super merci pour les explications, pourrais tu reprendre ces principes avec des petites vidoes dédiées et bien expliquées où on crée un petit projet en explicant ces principes ?
Toujours au top 👍
Très bonne vidéo, est ce que quelqu'un sait si la vidéo tutoriel sur Angular est construite suivant les principes SOLID?
Vraiment top ! Merci
Merci à toi pour le retour, bon code !
Bonjour,
Merci pour les explications !
J'ai juste un problème pour la compréhension par l'exemple que tu as fait, car je trouve que c'est semblable a OCP.
Super tips!
Comment appliquer les principes SOLID en front endroit, sur React par exemple ?
En programmation orientée objet, le principe ouvert/fermé (open/closed principle) affirme qu'une classe doit être à la fois ouverte (à l'extension) et fermée (à la modification). Il correspond au « O » de l'acronyme SOLID. « Ouverte » signifie qu'elle a la capacité d'être étendue. « Fermée » signifie qu'elle ne peut être modifiée que par extension, sans modification de son code source.
Excellent :)
Entièrement d'accord (même si SOLID ne s'applique pas nécessairement à tous les stacks / frameworks).
Hello, merci pour votre commentaire. Avez vous des exemples de stack ou de frameworks sur lesquelles les principes SOLID ne s’appliquent pas ? Bon code, Simon.
Merci
Avec plaisir, bon code. Simon.
Nice!!
Bonjour,
Aurais-tu des conseils plus spécifiques dans le design de script ? Il me semble que cette vidéo (qualitative) serve surtout du langage de programmation que du script.
En te remerciant,
Les principes SOLID s’applique principalement pour la programmation orienté objet. J’imagine que par script vous entendez la programmation procédurale, ou ces principes ne s’appliquent pas à la base.
@@codeursenior Oui tout à fait. Ce sur quoi je travaille (c'est pas mon domaine mais j'en ai besoin) tient de quelque chose plus procédural en effet (visual basic, donc orienté objet aussi cela dit). Du coup, dans cette veine, auriez-vous quelques bonnes pratiques du même genre ? Je n'en trouve pas...
@@elcarryboo9344 Hello, non rien de pertinent à dire ! Vous trouverez mieux ailleurs sur le procédural. Bon code, Simon.
Bonjour Simon ! Que penses-tu du livre "Clean Code" de Robert C. Martin ?
Ses conseils sont directement dans la ligne de clean code
Oncle Bob aka Robert C. Martin est une référence en la matière. Ce livre est à lire à plusieurs reprises dans ta carrière.
merci👍
Trop bien
meric simon.
Qu'est ce c'est principe fonctionne avec react js ?!
Ça fonctionne avec tous les langages et framework OOP, dont react fait parti
@@LordGerbito merci de ta réponse.
La Base c est de faire une conception avant de coder. Meme si elle est legere elle vous permettra d avoir une glibale du projet de poser les bases. Et ensuite n empeche de revoir cette conception au cours du codage.
Je suppose que vous vouliez dire “une vision globale du projet avant de poser les bases”. Je suis intéressé par ce type de pratique, qui consiste à concevoir le plan avant de créer. Je m’étais renseigné sur les diagrammes de classes avec l’UML. Mais je me demandais s’il existe des façons logiques, théoriques, des questions à poser pour orienter notre conception dans le bon sens. Existe-t-il des ouvrages ou des cours pour apprendre à faire une conception efficace ?
Oui, realiser un dossier de conception à l ancienne, biensure c est inutile pour les petits projet. Bien que...
UML peut aider, j ai lu UML 2 en action tres bon bouquin.
Un autre nouquin qui mais qu il faut avoir lu car il vous donne la demarche c est UML2 modeliser une application web.
Il doit exister des bouquins plus recent, mais ca fait maintenant quelques années que je ne fais plus de projet au forfait...
Peux tu partager tes notes ?
L'inversion de dépendance permet à une couche inférieure d'envoyer des messages à la couche supérieure tout en respectant le principe de ségrégation d'interface
Voici la réponse de ChatGPT, il a été meilleur que moi ce qui est rare et surprenant :
"
Cette affirmation est en partie vraie. L'inversion de dépendance peut effectivement permettre à une couche inférieure de communiquer avec une couche supérieure grâce aux abstractions, mais ce n'est pas vraiment le but principal du DIP. Le DIP vise principalement à découpler les modules pour la flexibilité et la maintenance. Le fait que la couche inférieure "envoie des messages" à la couche supérieure est plutôt une conséquence de cette dépendance inversée, mais cela peut être réalisé de différentes manières et pas seulement par l'inversion de dépendance.
Quant au respect du principe de ségrégation d'interface, il est indépendant du DIP mais peut être utilisé conjointement pour s'assurer que les interfaces (abstractions) utilisées dans l'inversion de dépendance sont propres et spécifiques à leurs responsabilités.
"
pour un dev, ne pas oublier le BSP, non pas le board support package (très utile), mais plus genetalement il s'agit du bon sens paysan, trop souvent oublié.
*generalement
DDD=domain driven design 😅
Augmentation positive de 0.5 😮
Top merci
👍
Et le YOP ? UA-cam Only Principle : quand on parle de code, on ne montre que du code
Et l'UML ?
"C’est la seule façon d’écrire du code propre !"
Ah bon. Donc il n'existait pas de code propre avant l'invention de SOLID ?
C'est comme Bruno Latour qui disait qu'un pharaon ne pouvait pas être mort de la tuberculose car Koch n'a découvert le bacille qu'au 19ème siècle.
On respectait ces principes avant qu'ils ne soient formalisés et nommés. Ou on s'exposait à des problèmes.
Quand on voit tout le code dégueu à reprendre... apparemment meme aujourd'hui c'est pas souvent respecté...
Quand ton propre code commence à te faire chier, il est temps de faire marche arrière.
Les explications ne sont pas claires dsl. On comprend dans les grandes lignes mais pas suffisant pour mettre en pratique
Hello, merci pour ton retour. Cette vidéo se veut généraliste, chaque point de SOLID mériterait une vidéo complète et plus détaillé sur le sujet. Je me note ça !
Bon code,
Simon.
Tu as un truc dans les oreilles.
Trop fort ton principe de coder des données en dur et d'essayer d'améliorer ta merde après coup
Améliorer la merde est mon métier. Qu’est ce que vous essayez de nous apporter sinon ?