🎉 Aujourd'hui est un grand jour ! 2 trucs incroyables viennent d'arriver ! On voit ma tête et on apprend à faire du clean code ! (Bon pas sûr que ce soit une super chose pour la 1ère) Apprenez à faire du clean code avec Laravel ! 💛
Hello, Sortir la logique métier du controlleur, c'est une très bonne idée. La mettre dans un calculateur, c'est une bonne idée. Mais ça reste encore bien améliorable :D Je note au moins 2 problèmes. Le nom PriceType et sa localisation. 1. "PriceType" on dirait que c'est une donnée, mais c'est une classe de service, on attend plus un verbe, en l'occurence un calculateur. PriceCalculator me semble plus approprié. 2. Le gros problème c'est l'explosion de la règle d'inversion de dépendances (le I de SOLID) , le calculateur est un objet de plus haut niveau que le produit. On ne devrait pas avoir ce calculateur dans le produit, on devrait plutôt passer le produit au calculateur pour lui demander le prix. Au passage on pourrait passer au calculateur des éléments de contexte comme la tva, les bons de reduction, etc qui entrent en jeu dans le calcul du prix. Quand on mixe données et traitement, c'est presque toujours un mauvais choix, ont doit s'orienter soit vers une classe qui représente de la data, soit vers une classe qui est un service. En séparant le produit du calculateur (aucun n'est une sous partie de l'autre), on est aussi mieux avec le SRP ;)
Je comprends ta solution ! Bien vu, il aurait mieux valu créer un service 🤔 Je tentais de me débarrasser de la boucle que l'on allait retrouver potentiellement plusieurs fois dans l'application pour faire la part belle au O de SOLID 🪨 Mais ça, je pense que tu l'avais déjà compris, je te remercie pour tes précieux conseils !
Merci beaucoup pour cette explication ! On a donc un modèle qui détient la logique. J'avais l'habitude de créer des "Services" qui recevaient le modèle et en faisaient quelque chose. Au final, le modèle n'était qu'un simple objet de transfert dénué de logique.
Aborder le Clean code avec Laravel et PHP 8 quand on a fait du java avancé pendant plusieurs années çà facilite tout le travail 😀 Merci pour le partage
🎉 Aujourd'hui est un grand jour ! 2 trucs incroyables viennent d'arriver !
On voit ma tête et on apprend à faire du clean code ! (Bon pas sûr que ce soit une super chose pour la 1ère)
Apprenez à faire du clean code avec Laravel ! 💛
Hello,
Sortir la logique métier du controlleur, c'est une très bonne idée.
La mettre dans un calculateur, c'est une bonne idée.
Mais ça reste encore bien améliorable :D
Je note au moins 2 problèmes. Le nom PriceType et sa localisation.
1. "PriceType" on dirait que c'est une donnée, mais c'est une classe de service, on attend plus un verbe, en l'occurence un calculateur. PriceCalculator me semble plus approprié.
2. Le gros problème c'est l'explosion de la règle d'inversion de dépendances (le I de SOLID) , le calculateur est un objet de plus haut niveau que le produit.
On ne devrait pas avoir ce calculateur dans le produit, on devrait plutôt passer le produit au calculateur pour lui demander le prix.
Au passage on pourrait passer au calculateur des éléments de contexte comme la tva, les bons de reduction, etc qui entrent en jeu dans le calcul du prix.
Quand on mixe données et traitement, c'est presque toujours un mauvais choix, ont doit s'orienter soit vers une classe qui représente de la data, soit vers une classe qui est un service.
En séparant le produit du calculateur (aucun n'est une sous partie de l'autre), on est aussi mieux avec le SRP ;)
Je comprends ta solution ! Bien vu, il aurait mieux valu créer un service 🤔
Je tentais de me débarrasser de la boucle que l'on allait retrouver potentiellement plusieurs fois dans l'application pour faire la part belle au O de SOLID 🪨
Mais ça, je pense que tu l'avais déjà compris, je te remercie pour tes précieux conseils !
@@LaravelJutsu pas de quoi :)
Faut pas avoir peur d'y aller par étape.
Tu as encapsulé la logique qui allait se repeter, c'est une très bonne chose :)
Ça fait plaisir de voir ta tête 😊
Exactement, chaque est bien en son temps
Merci beaucoup pour cette explication !
On a donc un modèle qui détient la logique.
J'avais l'habitude de créer des "Services" qui recevaient le modèle et en faisaient quelque chose.
Au final, le modèle n'était qu'un simple objet de transfert dénué de logique.
Aborder le Clean code avec Laravel et PHP 8 quand on a fait du java avancé pendant plusieurs années çà facilite tout le travail 😀 Merci pour le partage
Exactement 🫡
😀, comme toujours, au top !!
Toujours bien fait 💪
Rien que de la qualité :-) merci
Super intéressant
Top !
Hello
thank you for your tutorial (Finally, you showed up your face)
You're welcome 🤗
Yesss at last!
@@LaravelJutsu keep it going bro