ca revient à faire une machine à états ou workflow. Une classe par state + une methode par state dans le service c'est bon pour les petits systèmes, ca peut vite devenir embettant a maintenir. symfony propose un composant Workflow abolument genial pour ce genre de problématique. La logique états puis transitions entre états possibles est définie a un endroit. Le code s'appuie sur cette definition pour autoriser ou non les objets a passer d'un état a un autre. c'est super simple et très efficace. Meme dans le contexte étude de design pattern, l'approche du composant workflow mérite le détour par sa simplicité et efficacité.
Bonjour, J'aimerais plus de detail sur ce pattern, je vois, par exemple, que le "save" est fait dans l'objet NewStateOrder. Imaginons que la logique soit plus complexe, par exemple, si je mets votre exemple dans un contexte : imaginons une application de gestion pour laposte, et la fonctionnalité "ship" doit indiquer à l'api laposte que le livreur à bien envoyé le colis ainsi qu'envoyer un mail au client. La logique sera donc dans le ProcessingOrderState comme suit ou ailleur ? : class ProcessingOrderState implement OrderStateInterface { public function __construct(private $mailerService: Mailer, private $apiLaposte: ApiLaposte){} public function ship(Order $order){ $this->apiLaposte->send($order); $this->mailerService->send($order->getUser(), "Votre colis est expédié"); $order->status = "shipped"; $order->save(); } [... autre methode avec les exceptions] }
Si le livreur a bien envoyé le colis il serait là oui, ou le State qui sied le mieux L'exemple est simple pour expliquer le principe, mais effectivement il faut parfois élargir sa vision voire même combiner les Design Patterns !
Tu gères trop bien 🔥. Je ne connaissais pas ce Design Pattern et il est super utile pour un projet sur lequel je travaillais. Merci ❤
Merci 🤩
C'est l'un des DP que j'aime beaucoup, appelé aussi 'State Machine' ...
Merci pour ton commentaire !
ca revient à faire une machine à états ou workflow. Une classe par state + une methode par state dans le service c'est bon pour les petits systèmes, ca peut vite devenir embettant a maintenir.
symfony propose un composant Workflow abolument genial pour ce genre de problématique. La logique états puis transitions entre états possibles est définie a un endroit. Le code s'appuie sur cette definition pour autoriser ou non les objets a passer d'un état a un autre. c'est super simple et très efficace. Meme dans le contexte étude de design pattern, l'approche du composant workflow mérite le détour par sa simplicité et efficacité.
Excellent! Je connaissais mais ça mérite que je jette un oeil de nouveau, il me semble que quelqu'un avait tenté de l'adapter avec Laravel
Comment gerer le front avec cette stratégie ? genre afficher le btn qui faut avec le prochain statut ?
J implémenterai la logique dans le OrderResource pour avoir accès à ce que je veux au front
Bonjour,
J'aimerais plus de detail sur ce pattern, je vois, par exemple, que le "save" est fait dans l'objet NewStateOrder.
Imaginons que la logique soit plus complexe,
par exemple, si je mets votre exemple dans un contexte : imaginons une application de gestion pour laposte, et la
fonctionnalité "ship" doit indiquer à l'api laposte que le livreur à bien envoyé le colis ainsi qu'envoyer un mail au
client.
La logique sera donc dans le ProcessingOrderState comme suit ou ailleur ? :
class ProcessingOrderState implement OrderStateInterface {
public function __construct(private $mailerService: Mailer, private $apiLaposte: ApiLaposte){}
public function ship(Order $order){
$this->apiLaposte->send($order);
$this->mailerService->send($order->getUser(), "Votre colis est expédié");
$order->status = "shipped";
$order->save();
}
[... autre methode avec les exceptions]
}
Si le livreur a bien envoyé le colis il serait là oui, ou le State qui sied le mieux
L'exemple est simple pour expliquer le principe, mais effectivement il faut parfois élargir sa vision voire même combiner les Design Patterns !