Ok sur la theorie, dans la pratique, commencez par un bon if else des familles (plus rapide et optimisé), meme si pas solid et si besoin refacto par la suite, si besoin (spoil : quasiment jamais besoin)
J'ai utilisé un truc qui s'appelle Loom pour cette vidéo, j'ai une version gratuite pendant 14 jours. Sinon avec le macbook j'utilise quicktime et je me crée meeting un google meet ou je partage mon écran et je peux avec l'OS intégrer ma caméra sur mon partage d'écran 😓
Si les objets dont on souhaite calculer l'aire ne sont fonctionnellement pas tous un sous ensemble de "Shape", on peut utiliser les "Protocols" à la place des "ABCs".
Oui cette technique fonctionne mais ce n'est qu'un cas particulier d'une technique plus large. Si on a un code du type (pardon, je ne sais pas faire d'indentation dans un commentaire youtube). def toto(n): if n==0: return 2 elif n==1: return 12 elif n==2: return 47 on peut le remplacer par def toto(n): t=[2, 12, 47] return t[n] En gros, on stock utilise une indirection pour faire la même chose. Dans la liste précédente, rien n'empêche de mettre des fonctions. Ça règle le problème des if mais ça ne règle pas le fait qu'il faut maintenir la liste des fonctions. Une solution est de déplacer l'information pertinente pour le « if » DANS l'argument. Pour le premier exemple, on peut faire un truc du genre def toto(n): return n[1] Qu'on peut appeler par toto( (2, 47) ). On peut évidemment considérer un couple dont le second membre est une fonction et faire def aire(s): return s[1](s) On peut aussi faire des structures ou des classes. Bref, il y a plein de techniques.
Je ne suis pas sûr de bien comprendre. Dans votre cas, on ne calcule pas uniquement le résultat qui nous intéresse, mais tous les résultats possibles pour à la fin renvoyer uniquement le bon ? En terme de temps de calcul, ça me semble pas terrible...
@@PhunkyBob En ce qui concerne l'optimisation sur le premier if, passer de la version 1 à la version 2 (celle avec le premier tableau), c'est le genre de chose que fait gcc en -O3. Il suffit de regarder l'assembleur produit. Donc j'imagine que ça doit être totalement débile.
Merci ça fait plaisir, content que ça t'es utile :) Il y a cet exemple qui est tiré livre de Martin Fowler "Refactoring, improving the design of existing code" : github.com/emilybache/Theatrical-Players-Refactoring-Kata/tree/main/python. C'est un exo pas mal pour le polymorphisme, qui peut te faire sortir des class StandardBonus, BigBonus, Audience... Je t'en dis pas plus. D'ailleurs sur ce repo de Emily Bache, il y a tout plein de Kata pour s'amuser !
Je ne vais pas regarder la vidéo mais commenter le titre, en disant ce qui suit : le titre ne devrait pas être comment coder sans if Mais plutôt comment ne plus utiliser le if pour décider quel type ou sous type d’algorithme on exécute. Le if n’est pas fait pour ça.
Hello, dans ce cas precis, ca serait pas plus simple un bête dictionaire avec en index le nom de la forme et en valeur des lambdas qui font le calcul ?
ça marche très certainement ! Il y a toujours 1 000 manières différentse de résoudre un même problème, c'est ça qui est beau :) Mais là c'était vraiment juste un exemple pour montrer le principe du polymorphisme !
Pourquoi tu utilises Python avec les types (qui seront totalement ignoré quand le code sera bytecodé) ? Dans le sens, pourquoi ne pas aller avec un autre langage ?
Hello merci pour ton commentaire ! J'avoue que c'est une raison plus "professionnelle" car je suis dans la data, et on y fait beaucoup de Python. Sa syntaxe est super simple, proche du pseudo-code, ce qui rend le code très lisible et donc "clean codable" facilement ;)
21 lignes contre 47. Vous doublez le nombre d'instructions au final. Mais pas de problème la "responsabilité" de cela est renvoyée à la machine qui devra trimer 2 x plus pour exécuter votre code. 😅
Ici je ne parle que de principes Clean Code et Solid. La performance d’un code est évidemment différente de sa lisibilité et de sa maintenance ! Mais tu as raison oui, si la performance était l’objectif de cette chaîne je ferais fausse route :) Bonne journée !
@@bossgd100 rappelle moi de ne pas t'embaucher. Alors ok, pour une todolist c'est too much, mais dans le cadre pro, sur une app scalable sans effet de bord (architecture hexagonale par exemple ), c'est l'objectif. Peu importe le nombre de lignes de code
@@driiade6311 on se rassure comme on peut avec le dernier pattern du nouveau gourou à la mode. C'est vrai que le code était mbuvable et inmaintenable avant la sortie du livre clean code et l'invention de solid ;)
Faut relativer avec SOLID, des fois, c'est vraiment long et pénible de suivre la méthode qui appel l'autre qui appel l'autre qui appel l'autre qui finalement, n'était pas celle là mais l'autre... Quand cela devient compliqué, là tu sépares.
Dans ce cas précis, je préfère 3 if. Plus lisible que 3 classes, pas besoin de 3 classes stockées dans la heap (donc + de travail pour le GC et + de poids dans la ram). Et pour éviter les suprises en prod, un bon test unitaire, ça évite de serrer les fesses à chaque modification. Mais sinon ça permet d’expliquer simplement le pattern en lui même. Pour davantage de possibilités et si il y a de l’ioc pourquoi pas, sinon peu d’intérêt dans ce cas précis.
C'est sûr qu'avec les bons tests unitaires on est à l'abri ! Côté Heap / Performance, j'avoue m'y connaître que très peu. L'idée était vraiment de montrer le principe avec un exemple compréhensible. Merci pour le commentaire en tout cas !
@@LaMaliceCode tkt ils ont tjrs ca comme argument. L opti. Et apres tu reprends un projet a 40 milliard de if qui tourne presque plus. Et toi tous tes projets a 40 milliard de class y a jamais eu de soucis. C est du vecu. Ca devient insupportable de lire ça. Bref gg pour le video.
Parfait pour les gens comme moi qui déteste les conifères je recommande
Super vidéo, un banger mon gars masterclass
Pour éviter les if ... else ... on peut utiliser un match ... case ... 😂
Trop cool les polymorphisme !
Ok sur la theorie, dans la pratique, commencez par un bon if else des familles (plus rapide et optimisé), meme si pas solid et si besoin refacto par la suite, si besoin (spoil : quasiment jamais besoin)
Une vidéo banger comme d hab. Merci d être revenu Lamalice !
Merci ! A un moment donné, les "if" ça dégage
@@LaMaliceCode t'es ifophobe ????
Très bonne vidéo!
Et 200 abonnés de plus entre le moment où j’ai vu cette vidéo (samedi dernier) et ce mardi donc chapeau bas!
Merci pour ce retour !ça fait plaisir :)
@@LaMaliceCode Plaisir partagé!
Vu que le sujet est abordé dans la vidéo, je confirme qu’une vidéo sur les principes SOLID serait une excellente idée!
Merci! Super clair 👌
Solide le mec !
Hyper intéressant, merci du tips !
J’adore et oui une vidéo sur les principes solid serait top! Par contre tu kiffes vraiment python ou y’a moyen de faire avec un autre langage? 😂
T'utilise quel outils pour enregistrer l'écran avec la caméra?
J'ai utilisé un truc qui s'appelle Loom pour cette vidéo, j'ai une version gratuite pendant 14 jours. Sinon avec le macbook j'utilise quicktime et je me crée meeting un google meet ou je partage mon écran et je peux avec l'OS intégrer ma caméra sur mon partage d'écran 😓
Si les objets dont on souhaite calculer l'aire ne sont fonctionnellement pas tous un sous ensemble de "Shape", on peut utiliser les "Protocols" à la place des "ABCs".
en gros tu utilise une fonction qui elle même donne un résultat en fonction du type de l'argument
On va pas se mentir
Oui cette technique fonctionne mais ce n'est qu'un cas particulier d'une technique plus large.
Si on a un code du type (pardon, je ne sais pas faire d'indentation dans un commentaire youtube).
def toto(n):
if n==0: return 2
elif n==1: return 12
elif n==2: return 47
on peut le remplacer par
def toto(n):
t=[2, 12, 47]
return t[n]
En gros, on stock utilise une indirection pour faire la même chose.
Dans la liste précédente, rien n'empêche de mettre des fonctions.
Ça règle le problème des if mais ça ne règle pas le fait qu'il faut maintenir la liste des fonctions.
Une solution est de déplacer l'information pertinente pour le « if » DANS l'argument.
Pour le premier exemple, on peut faire un truc du genre
def toto(n):
return n[1]
Qu'on peut appeler par toto( (2, 47) ).
On peut évidemment considérer un couple dont le second membre est une fonction et faire
def aire(s):
return s[1](s)
On peut aussi faire des structures ou des classes.
Bref, il y a plein de techniques.
Que Dieu te bénisse mon frère
Je ne suis pas sûr de bien comprendre. Dans votre cas, on ne calcule pas uniquement le résultat qui nous intéresse, mais tous les résultats possibles pour à la fin renvoyer uniquement le bon ?
En terme de temps de calcul, ça me semble pas terrible...
@@PhunkyBob En ce qui concerne l'optimisation sur le premier if, passer de la version 1 à la version 2 (celle avec le premier tableau), c'est le genre de chose que fait gcc en -O3. Il suffit de regarder l'assembleur produit. Donc j'imagine que ça doit être totalement débile.
Comment rendre le code encore plus abjecte 😂
@@rokibgyimah8675😂 excellent le commentaire
Je suggère d'utiliser les interfaces
100 if, ça fait beaucoup trop 🤣🤣🤣🤣
Bon, mais c'est quand même un titre putaclic 🤣🤣
t'as résumé en 5 minutes un concept simple que mes profs ont toujours réussi à rendre fumeux
t'aurais des exercices de refactoring à conseiller ?
Merci ça fait plaisir, content que ça t'es utile :) Il y a cet exemple qui est tiré livre de Martin Fowler "Refactoring, improving the design of existing code" : github.com/emilybache/Theatrical-Players-Refactoring-Kata/tree/main/python. C'est un exo pas mal pour le polymorphisme, qui peut te faire sortir des class StandardBonus, BigBonus, Audience... Je t'en dis pas plus. D'ailleurs sur ce repo de Emily Bache, il y a tout plein de Kata pour s'amuser !
Le refactoring ça se fait sur une base de code conséquente ; on ne peut pas en faire "des exercices".
Je ne vais pas regarder la vidéo mais commenter le titre, en disant ce qui suit :
le titre ne devrait pas être comment coder sans if
Mais plutôt comment ne plus utiliser le if pour décider quel type ou sous type d’algorithme on exécute.
Le if n’est pas fait pour ça.
C’est exactement ça merci à toi !
Hello, dans ce cas precis, ca serait pas plus simple un bête dictionaire avec en index le nom de la forme et en valeur des lambdas qui font le calcul ?
ça marche très certainement ! Il y a toujours 1 000 manières différentse de résoudre un même problème, c'est ça qui est beau :) Mais là c'était vraiment juste un exemple pour montrer le principe du polymorphisme !
Pourquoi tu utilises Python avec les types (qui seront totalement ignoré quand le code sera bytecodé) ? Dans le sens, pourquoi ne pas aller avec un autre langage ?
Hello merci pour ton commentaire ! J'avoue que c'est une raison plus "professionnelle" car je suis dans la data, et on y fait beaucoup de Python. Sa syntaxe est super simple, proche du pseudo-code, ce qui rend le code très lisible et donc "clean codable" facilement ;)
21 lignes contre 47. Vous doublez le nombre d'instructions au final. Mais pas de problème la "responsabilité" de cela est renvoyée à la machine qui devra trimer 2 x plus pour exécuter votre code. 😅
Ici je ne parle que de principes Clean Code et Solid. La performance d’un code est évidemment différente de sa lisibilité et de sa maintenance ! Mais tu as raison oui, si la performance était l’objectif de cette chaîne je ferais fausse route :) Bonne journée !
tt à fait, c'est de la branlette
@@bossgd100 rappelle moi de ne pas t'embaucher. Alors ok, pour une todolist c'est too much, mais dans le cadre pro, sur une app scalable sans effet de bord (architecture hexagonale par exemple ), c'est l'objectif. Peu importe le nombre de lignes de code
@@warfielkoc est exactement ça.
Trop de mauvais dev qui te pondent un truc imbuvable et inmaintenable.
@@driiade6311 on se rassure comme on peut avec le dernier pattern du nouveau gourou à la mode. C'est vrai que le code était mbuvable et inmaintenable avant la sortie du livre clean code et l'invention de solid ;)
vive les if et les goto. 😁
Perso j'appelle ça un pattern strategy
Clean Code + Solid 😋Je partage
Faut relativer avec SOLID, des fois, c'est vraiment long et pénible de suivre la méthode qui appel l'autre qui appel l'autre qui appel l'autre qui finalement, n'était pas celle là mais l'autre... Quand cela devient compliqué, là tu sépares.
Dans ce cas précis, je préfère 3 if. Plus lisible que 3 classes, pas besoin de 3 classes stockées dans la heap (donc + de travail pour le GC et + de poids dans la ram).
Et pour éviter les suprises en prod, un bon test unitaire, ça évite de serrer les fesses à chaque modification.
Mais sinon ça permet d’expliquer simplement le pattern en lui même. Pour davantage de possibilités et si il y a de l’ioc pourquoi pas, sinon peu d’intérêt dans ce cas précis.
C'est sûr qu'avec les bons tests unitaires on est à l'abri ! Côté Heap / Performance, j'avoue m'y connaître que très peu. L'idée était vraiment de montrer le principe avec un exemple compréhensible. Merci pour le commentaire en tout cas !
@@LaMaliceCode tkt ils ont tjrs ca comme argument. L opti.
Et apres tu reprends un projet a 40 milliard de if qui tourne presque plus.
Et toi tous tes projets a 40 milliard de class y a jamais eu de soucis.
C est du vecu.
Ca devient insupportable de lire ça.
Bref gg pour le video.