Bonjour Jason, en ce matin du 24 Décembre 2023 j'ai appris pas mal de choses sur les patterns ( MVC, MVVM, SOLID ) et vraiment c'est un plus et tes explications sont toujours simples à comprendre les concepts. Joyeux Noel à toi, profite bien auprès des siens.
Ton tuto est magnifique. Compréhensible, claire nickel ! Merci à toi. Tes remarques de fin sont très pertinente, étant moi même entre le niveau débutant et intermédiaire, souvent quand je vois des gens appliquer ces principes ça me semble high level. En réalité il faut juste que je m'y mette
top d'habitude les videos survolent ces concepts et les exemples sont incompréhensible, ta manière de faire avec ce qu'il ne faut pas faire puis ce qu'il faut faire est top
Superbe vidéo! Très bonnes explications très claires. Par contre pour le dernier principe; le DIP., j'aurais deux petites questions: - Qu'est qu'un module de haut niveau/bas niveau? - Est ce que ce principe s'applique uniquement au connexions externes (database, APi)? Parce que j'ai cherché d'autre vidéos sur le sujet mais tous se contentent de donner finalement le même exemple. Merci pour les explications 😁
On parle de bas ou haut niveau de manière relative (ex : un module est plus haut niveau qu'un autre, mais pourrait tout aussi bien être plus bas niveau qu'un énième). Cela dépend donc de ta conception. Imaginons un programme qui fait un rendu d'interface : une méthode pour afficher un bouton est plus bas niveau qu'une méthode pour afficher un widget (le bouton, faisant partie des widgets). C'est assez facile à identifier dans le code : quand tes fonctions manipulent des types concrets alors qu'il y a un type plus haut dans la hiérarchie (classe mère, interface, ...) il vaut mieux manipuler ces abstractions directement. Dans l'exemple précédent : Widget serait l'abstraction de Button, donc on manipule directement des widgets et non des boutons, et on se sert du polymorphisme pour que le comportement soit adapté à chaque type de widget naturellement. Ce principe s'applique donc partout comme tu peux le constater. Comme l'idée d'avoir un outil pour écrire dans un flux (le flux est abstrait), et on peut ainsi écrire : sur une sortie (écran), dans un fichier, sur un périphérique (imprimante), etc.
Bonjour, Merci beaucoup pour ton travail Jason. Cela m'a beaucoup aidé à devenir développeur. Tes explications des principes SOLID sont les plus claires que j'ai trouvées sur CZcams. Je fais du C# en front-end et du cobol en back-end. Penses-tu un jour faire une formation sur le Cobol ? Merci et bonne continuation. Cordialement.
Bonjour, non, je ne connais pas COBOL et n'ai pas de besoin personnel de l'apprendre un jour et donc, de l'enseigner. Et content que cette vidéo ait été claire pour toi 👍
Merci pour cette vidéo super instructive, merci de prendre ton temps de donner des explications claires pour les débutants. À 44:00 cela fonctionnerait t-il d'appeler la classe IDatabaseConnector dans la classe NewsRepository, la classe MySQLConnector remplace-t-elle la classe IDatabaseConnector ?
Oui cela fonctionnerait, mais à ce moment-là, on ne respecte plus les principes solides car notre classe dépendrait d'un élément concret (connecteur MySQL) plutôt qu'une abstraction.
je suis arrivé dans une nouvelle entreprise cette année et il ne respecte meme pas le premier principe, c'est intestable car trop gros et donc il ne font pas de test. les mecs ont 20 ans d'experiences et ca fait peur. KISS est le meilleur principe. Merci en tout cas pour la video !
Il n'y a pas de meilleur principe, mais une bonne application de ceux-ci dans un contexte adéquat. Et oui, on pourrait croire que des gens à X années d'expérience sont forcément compétents et/ou font les choses convenablement, mais dans la réalité... 👀
Au niveau de l'inversion des dépendances est-ce qu'on peut faire IDatabaseConnector comme étant une interface dans les langages qui ont la notion d'interface ?
Je ne sais pas si c'est moi qui comprend mal, mais j''ai l'impréssion que le DIP est un sous cas du OCP Quand on crée une interface que les 2 classes concretes vont implémenter, ça facilite l'ajout de nouvelles features, donc même finalité que l'OCP A moins que le but 1er ce soit vraiment de ne pas dépendre d'une classe concrète comme dans l'exemple avec la connexion mysql? Tu peux me donner ton avis stp ? Sinon j'ai adoré ton tuto, merci!
Chaque principe est bien distinct : le principe ouvert/fermé évoque la manière d'écrire des composants logiciels qui peuvent être étendues sans devoir apporter de modifications au code existant, tandis que le principe d'inversion de dépendance est la manière de structurer ces dépendances pour les différentes parties du système. Dit autrement : le principe ouvert/fermé considère qu'il faut ajouter des fonctionnalités par extension du contenu existant plutôt que sa modification. Et le principe d'inversion de dépendance, qu'il faut davantage travailler par abstraction que via des données concrètes.
merci pour cette vidéo !! J'ai une question sur la partie Ouvert/fermé. Sur l'exemple cité avec les combattants, comment faire le choix entre une classe abstraite et une interface ?
Une classe abstraite met en commun des éléments qui ont un comportant similaire, là où une interface et une contrat pour ajouter des fonctionnalités à plusieurs classes, même si elles ne font pas partie de la même hiérarchie 👍
Bonjour Merci pour cette vidéo les questions ne manquent jamais aux entretiens. Cependant j'ai un soucis de compréhension. Sur le *PRINCIPE Ouvert/fermé* : comment j' _attack()_ avec *Warrior* ? Est ce que c'est la classe *FightingSystem* que je vais appeler dans mon *main* en lui passant en paramètre *Warrior*? pouvez vous svp impliquer comment faire que dans un programme j' _attack()_ avec *Warrior* Merci
Bonjour, l'exemple que tu demandes est celui montré dans la vidéo justement. On fait implémenter à la classe Warrior l'interface Fighter. Il devient alors un combattant capable de...se battre, tout simplement 😉
Je valide les cinq principes (cela leur est sans doute égal). Maintenant je vais réfléchir à comment les appliquer dans du code en C. Pour S et O, facile. Pour L je crois que je vois. Pour I et D on va rire.
Cela s'applique surtout au paradigme objet, donc ne concerne pas directement un langage comme le C, même si comme je l'ai dit, certaines idées sont et peuvent être adaptés à un langage dont le paradigme est du procédural. Maintenant, d'autres principes sont/seront abordés sur la chaîne, et applicables plus précisément à ce genre de langage 👍
Meilleur théorie: ce type *EST* l'origine de *TOUS* les languages de programmations. Il a créé ASM, puis C, C++, B, Fortran, COBOL, Python, Java, C#, javascript, R, Ruby, Pearl, Rust, Go, Lua et son dernier c'est carbon 💀
Bonjour Jason, en ce matin du 24 Décembre 2023 j'ai appris pas mal de choses sur les patterns ( MVC, MVVM, SOLID ) et vraiment c'est un plus et tes explications sont toujours simples à comprendre les concepts.
Joyeux Noel à toi, profite bien auprès des siens.
Merci et de bonnes fêtes à toi 🙏
Ton tuto est magnifique. Compréhensible, claire nickel ! Merci à toi.
Tes remarques de fin sont très pertinente, étant moi même entre le niveau débutant et intermédiaire, souvent quand je vois des gens appliquer ces principes ça me semble high level. En réalité il faut juste que je m'y mette
Oui, le "niveau", c'est toujours subjectif, alors tout peut être abordé et étudié, quel que soit là où tu te situes ou penses te situer 🙂
top d'habitude les videos survolent ces concepts et les exemples sont incompréhensible, ta manière de faire avec ce qu'il ne faut pas faire puis ce qu'il faut faire est top
Merci du retour 👍
Merci chef pour tes explications
Super tuto sur les principes SOLDI (ça passe bien aussi) 😊
👍
Superbe vidéo! Très bonnes explications très claires. Par contre pour le dernier principe; le DIP., j'aurais deux petites questions:
- Qu'est qu'un module de haut niveau/bas niveau?
- Est ce que ce principe s'applique uniquement au connexions externes (database, APi)? Parce que j'ai cherché d'autre vidéos sur le sujet mais tous se contentent de donner finalement le même exemple.
Merci pour les explications 😁
On parle de bas ou haut niveau de manière relative (ex : un module est plus haut niveau qu'un autre, mais pourrait tout aussi bien être plus bas niveau qu'un énième). Cela dépend donc de ta conception. Imaginons un programme qui fait un rendu d'interface : une méthode pour afficher un bouton est plus bas niveau qu'une méthode pour afficher un widget (le bouton, faisant partie des widgets).
C'est assez facile à identifier dans le code : quand tes fonctions manipulent des types concrets alors qu'il y a un type plus haut dans la hiérarchie (classe mère, interface, ...) il vaut mieux manipuler ces abstractions directement. Dans l'exemple précédent : Widget serait l'abstraction de Button, donc on manipule directement des widgets et non des boutons, et on se sert du polymorphisme pour que le comportement soit adapté à chaque type de widget naturellement.
Ce principe s'applique donc partout comme tu peux le constater. Comme l'idée d'avoir un outil pour écrire dans un flux (le flux est abstrait), et on peut ainsi écrire : sur une sortie (écran), dans un fichier, sur un périphérique (imprimante), etc.
Merci monsieur pour cette vidéo
👍
Bonjour,
Merci beaucoup pour ton travail Jason. Cela m'a beaucoup aidé à devenir développeur. Tes explications des principes SOLID sont les plus claires que j'ai trouvées sur CZcams. Je fais du C# en front-end et du cobol en back-end. Penses-tu un jour faire une formation sur le Cobol ? Merci et bonne continuation.
Cordialement.
Bonjour, non, je ne connais pas COBOL et n'ai pas de besoin personnel de l'apprendre un jour et donc, de l'enseigner. Et content que cette vidéo ait été claire pour toi 👍
C'est très intéressant ❤❤
Merci
Génial ❤
c'est top Merci! 👍
👋
Merci pour cette vidéo super instructive, merci de prendre ton temps de donner des explications claires pour les débutants.
À 44:00 cela fonctionnerait t-il d'appeler la classe IDatabaseConnector dans la classe NewsRepository, la classe MySQLConnector remplace-t-elle la classe IDatabaseConnector ?
Oui cela fonctionnerait, mais à ce moment-là, on ne respecte plus les principes solides car notre classe dépendrait d'un élément concret (connecteur MySQL) plutôt qu'une abstraction.
Merci
je suis arrivé dans une nouvelle entreprise cette année et il ne respecte meme pas le premier principe, c'est intestable car trop gros et donc il ne font pas de test. les mecs ont 20 ans d'experiences et ca fait peur.
KISS est le meilleur principe.
Merci en tout cas pour la video !
Il n'y a pas de meilleur principe, mais une bonne application de ceux-ci dans un contexte adéquat. Et oui, on pourrait croire que des gens à X années d'expérience sont forcément compétents et/ou font les choses convenablement, mais dans la réalité... 👀
Au niveau de l'inversion des dépendances est-ce qu'on peut faire IDatabaseConnector comme étant une interface dans les langages qui ont la notion d'interface ?
Oui, pour dépendre à ce moment-là de l'abstraction (l'interface) 👍
Je ne sais pas si c'est moi qui comprend mal, mais j''ai l'impréssion que le DIP est un sous cas du OCP
Quand on crée une interface que les 2 classes concretes vont implémenter, ça facilite l'ajout de nouvelles features, donc même finalité que l'OCP
A moins que le but 1er ce soit vraiment de ne pas dépendre d'une classe concrète comme dans l'exemple avec la connexion mysql?
Tu peux me donner ton avis stp ?
Sinon j'ai adoré ton tuto, merci!
Chaque principe est bien distinct : le principe ouvert/fermé évoque la manière d'écrire des composants logiciels qui peuvent être étendues sans devoir apporter de modifications au code existant, tandis que le principe d'inversion de dépendance est la manière de structurer ces dépendances pour les différentes parties du système.
Dit autrement : le principe ouvert/fermé considère qu'il faut ajouter des fonctionnalités par extension du contenu existant plutôt que sa modification. Et le principe d'inversion de dépendance, qu'il faut davantage travailler par abstraction que via des données concrètes.
Top 👍
1er commentaire d'Algérie, Merci pour tout .
Merci pour tout votre travail !
Il y a une faute de frappe à la fin :
- don't repeaT yourself
Ah, en effet, je ne l'avais pas vu celle-là 👍
merci pour cette vidéo !!
J'ai une question sur la partie Ouvert/fermé. Sur l'exemple cité avec les combattants, comment faire le choix entre une classe abstraite et une interface ?
Une classe abstraite met en commun des éléments qui ont un comportant similaire, là où une interface et une contrat pour ajouter des fonctionnalités à plusieurs classes, même si elles ne font pas partie de la même hiérarchie 👍
Bonjour Merci pour cette vidéo les questions ne manquent jamais aux entretiens.
Cependant j'ai un soucis de compréhension.
Sur le *PRINCIPE Ouvert/fermé* :
comment j' _attack()_ avec *Warrior* ? Est ce que c'est la classe *FightingSystem* que je vais appeler dans mon *main* en lui passant en paramètre *Warrior*?
pouvez vous svp impliquer comment faire que dans un programme j' _attack()_ avec *Warrior*
Merci
Bonjour, l'exemple que tu demandes est celui montré dans la vidéo justement. On fait implémenter à la classe Warrior l'interface Fighter. Il devient alors un combattant capable de...se battre, tout simplement 😉
Je valide les cinq principes (cela leur est sans doute égal).
Maintenant je vais réfléchir à comment les appliquer dans du code en C. Pour S et O, facile. Pour L je crois que je vois. Pour I et D on va rire.
Cela s'applique surtout au paradigme objet, donc ne concerne pas directement un langage comme le C, même si comme je l'ai dit, certaines idées sont et peuvent être adaptés à un langage dont le paradigme est du procédural.
Maintenant, d'autres principes sont/seront abordés sur la chaîne, et applicables plus précisément à ce genre de langage 👍
Enfin
Bonsoir Monsieur merci pour la video
Il y a t-il pas un tuto sur laravel ?
Bonjour, non pas encore : github.com/jasonchampagne/FormationVideo
théorie : ce type est à l'origine même de l'informatique, c'est pour ça qu'il connait autant de langage 🤣🤣
Non, je n'ai pas cette prétention 🤣
Meilleur théorie: ce type *EST* l'origine de *TOUS* les languages de programmations. Il a créé ASM, puis C, C++, B, Fortran, COBOL, Python, Java, C#, javascript, R, Ruby, Pearl, Rust, Go, Lua et son dernier c'est carbon 💀
Ou alors je ne suis qu'une IA depuis le début et j'ai berné tout le monde... qui sait 👀