Maîtrisez les principes SOLID : C’est la seule façon d’écrire du code propre !

Рет қаралды 43,077

Күн бұрын

👨🏻‍💻 Démarrer votre carrière de Développeur Professionnel :
www.angularsenior.fr/apply
***
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

Пікірлер: 93

@gippel1 10 ай бұрын

Merci beaucoup, super bien expliqué avec des exemples assez concret et des petits tips en plus (Le vert sur les PR) !

@DavidRENAUD-ss5yj 10 ай бұрын

Merci Simon pour ces explications claires (comme d'hab !)

@HyLsT16 10 ай бұрын

Explications très utiles et vraiment accessibles. Merci ! Tu qs vraiment une très bonne pédagogie !

@maxenceyrowah4261 10 ай бұрын

Vous m'avez manquez coach j'espere que vous allez super, bon retour parmi nous

@aliplaysgtr 10 ай бұрын

Excellent comme d'habitude, merci!

@Khalid15325 10 ай бұрын

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 !.

@louqmaneinoussa6649 10 ай бұрын

Madame Mac Michu😂 Merci de suivre vos élèves

@Khalid15325 10 ай бұрын

@@louqmaneinoussa6649 Madame Mac Michiouuu 😉

@louqmaneinoussa6649 10 ай бұрын

@@Khalid15325 autant pour moi 🌚

@Khalid15325 10 ай бұрын

@@louqmaneinoussa6649 No problem 😉

@saint14titan56 10 ай бұрын

Je vous aime madame Mac Michou, vous êtes trop chou 😅😅

@jonathantrilles8613 10 ай бұрын

Très instructif, merci!

@AkramButNot 10 ай бұрын

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.

@8area8 10 ай бұрын

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.

@BricBracASMR 10 ай бұрын

Merci beaucoup pour cette vidéo ! Tu expliques super bien !

@JeremyGasperowicz 10 ай бұрын

Toujours au top 👍

@is2m913 10 ай бұрын

Merci pour cette explication 👍

@LordGerbito 10 ай бұрын

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

@kremelandrykossonou1812 10 ай бұрын

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.

@didierochsenbein5818 4 ай бұрын

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...

@guilhemjoly 6 ай бұрын

Excellente vidéo, merci beaucoup pour tes explications.

@codeursenior 6 ай бұрын

Merci à toi pour le retour. Bon code !

@frankdearr2772 10 ай бұрын

excellent sujet, merci 👍

@jean-baptistebonaparte2200 10 ай бұрын

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 ?

@ThearsenikfromGmail 10 ай бұрын

Super tips!

@TheGetbackers007 9 ай бұрын

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 !

@sebastieng.9575 9 ай бұрын

Merci pour ces explications concises et de qualité.

@codeursenior 9 ай бұрын

Merci à toi pour ton retour ! Bon code, Simon.

@tamantaman 10 ай бұрын

Excellent :)

@Sql37 10 ай бұрын

Tellement enrichissant !!

@codeursenior 9 ай бұрын

Content que vous ayez pu vous enrichir ! 💰 j’espère que c’est légal !

@FredericPerat 10 ай бұрын

Nice!!

@pyroxis5269 9 ай бұрын

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.

@codeursenior 9 ай бұрын

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.

@maxwebstudio 10 ай бұрын

Vraiment top ! Merci

@codeursenior 10 ай бұрын

Merci à toi pour le retour, bon code !

@Tidusane 5 ай бұрын

Super intéressant merci pour ta vidéo

@codeursenior 5 ай бұрын

Avec plaisir, bon code à vous. Simon.

@mehdib8612 10 ай бұрын

Trop bien

@AA-nu7ht 8 ай бұрын

Très bonne vidéo, est ce que quelqu'un sait si la vidéo tutoriel sur Angular est construite suivant les principes SOLID?

@Razkazar 10 ай бұрын

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.

@patrickmooc5817 10 ай бұрын

Bonjour et merci pour ces explications ! Est-il possible de nous mettre à disposition la feuille de synthèse finale ? Merci d'avance !

@Shaffefr 10 ай бұрын

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 !

@dev-rachid 8 ай бұрын

merci👍

@poischiche2933 10 ай бұрын

Comment appliquer les principes SOLID en front endroit, sur React par exemple ?

@franssu2229 3 ай бұрын

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)

@codeursenior 3 ай бұрын

Bonjour, merci pour votre retour. Ce n'est pas possible de le faire au niveau de Shape ?

@franssu2229 3 ай бұрын

@@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)

@kremelandrykossonou1812 10 ай бұрын

@pH7Programming 9 ай бұрын

Entièrement d'accord (même si SOLID ne s'applique pas nécessairement à tous les stacks / frameworks).

@codeursenior 9 ай бұрын

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.

@herinandrianinaeloicharlyr1278 8 ай бұрын

Merci

@codeursenior 8 ай бұрын

Avec plaisir, bon code. Simon.

@mattcornic804 10 ай бұрын

Bonjour Simon ! Que penses-tu du livre "Clean Code" de Robert C. Martin ?

@xtunasil0 10 ай бұрын

Ses conseils sont directement dans la ligne de clean code

@wassimmehanna4402 10 ай бұрын

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.

@abdesselamkhadraoui8840 10 ай бұрын

meric simon.

@elcarryboo9344 9 ай бұрын

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,

@codeursenior 9 ай бұрын

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.

@elcarryboo9344 9 ай бұрын

@@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...

@codeursenior 9 ай бұрын

@@elcarryboo9344 Hello, non rien de pertinent à dire ! Vous trouverez mieux ailleurs sur le procédural. Bon code, Simon.

@hippiestafarii 10 ай бұрын

Peux tu partager tes notes ?

@moneyfr 10 ай бұрын

Tu laisses pas assez longtemps le code à l'image

@hydrogen6110 10 ай бұрын

la barre espace c'est pas mal mdr

@moneyfr 10 ай бұрын

@@hydrogen6110 j'ai plus les explications après

@yanntrad2304 10 ай бұрын

Sur pause. Tu lis et assimile le code et réécoute l'explication

@mehdib8612 10 ай бұрын

Qu'est ce c'est principe fonctionne avec react js ?!

@LordGerbito 10 ай бұрын

Ça fonctionne avec tous les langages et framework OOP, dont react fait parti

@mehdib8612 10 ай бұрын

@@LordGerbito merci de ta réponse.

@kremelandrykossonou1812 10 ай бұрын

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

@codeursenior 10 ай бұрын

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. "

@Roland-cy7ll 10 ай бұрын

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.

@Ibadez38 10 ай бұрын

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 ?

@Roland-cy7ll 10 ай бұрын

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...

@yasno4840 10 ай бұрын

Top merci

@codeursenior 10 ай бұрын

👍

@ascaroth2607 10 ай бұрын

Augmentation positive de 0.5 😮

@Seilesoso 8 ай бұрын

DDD=domain driven design 😅

@sauldetarse2339 10 ай бұрын

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é.

@sauldetarse2339 10 ай бұрын

*generalement

@geosesame6162 10 ай бұрын

Et le YOP ? KZfaq Only Principle : quand on parle de code, on ne montre que du code

@adriencbl 10 ай бұрын

Et l'UML ?

@juliennapoli 10 ай бұрын

Quand ton propre code commence à te faire chier, il est temps de faire marche arrière.

@IBelieveInCode 10 ай бұрын

"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 ?

@maldoror4035 10 ай бұрын

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.

@yanntrad2304 10 ай бұрын

Quand on voit tout le code dégueu à reprendre... apparemment meme aujourd'hui c'est pas souvent respecté...

@happycreeper6923 8 ай бұрын

Les explications ne sont pas claires dsl. On comprend dans les grandes lignes mais pas suffisant pour mettre en pratique

@codeursenior 8 ай бұрын

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.