Ce design pattern s'apparente très fortement à une machine à état
Je comprends le rapprochement avec une machine à états mais ça ne m'a pas l'air d'en être une du tout. Une machine a état se définie par les transitions entre les états. Un état est inerte et on suit des transitions pour aller d'état en état. Cela donne des propriétés très différentes : un état ne connais pas les autres destinations possibles à partir de lui. L'objectif c'est d'avoir une séparation entre le code métier et la navigation entre chaque partie et d'avoir une vision large du graphe[1] complet de la machine à états.
Il me semble que c'est plus une manière de chaîner des fonctions de manière très découpées.
Optional[State[HTTPContext]]
C'est pas un peu lourd à l'usage ça ? Le state pourrait pas lui-même être une sorte de type somme : Next[HTTPContext] | Final | Error ?
J'ai une dernière question, comment tu récupère ton résultat à la fin ? C'est à la charge du dernier State de faire ce qu'il faut ou tu introspecte le dernier état ?
C'est peut être pas clair donc avec ton exemple, si je veux faire quelque chose de cette requête, il faut :
ajouter un nouvel état qui fait suite à read body pour faire mon traitement
ou à la fin de StateMachine.run_from() je vais chercher dans mon dernier state les données qui viennent d'être parsées
[1]: cette notion de graphe est importantes pour certaines machines a états car ça permet de déduire des propriétés de l'algorithme comme par exemple prouver la terminaison.
# Machine à états ?
Posté par barmic 🦦 . En réponse au journal Sunday Python Pattern : Une machine à état toute simple. Évalué à 4.
Je comprends le rapprochement avec une machine à états mais ça ne m'a pas l'air d'en être une du tout. Une machine a état se définie par les transitions entre les états. Un état est inerte et on suit des transitions pour aller d'état en état. Cela donne des propriétés très différentes : un état ne connais pas les autres destinations possibles à partir de lui. L'objectif c'est d'avoir une séparation entre le code métier et la navigation entre chaque partie et d'avoir une vision large du graphe[1] complet de la machine à états.
Il me semble que c'est plus une manière de chaîner des fonctions de manière très découpées.
C'est pas un peu lourd à l'usage ça ? Le state pourrait pas lui-même être une sorte de type somme :
Next[HTTPContext] | Final | Error?J'ai une dernière question, comment tu récupère ton résultat à la fin ? C'est à la charge du dernier State de faire ce qu'il faut ou tu introspecte le dernier état ?
C'est peut être pas clair donc avec ton exemple, si je veux faire quelque chose de cette requête, il faut :
StateMachine.run_from()je vais chercher dans mon dernier state les données qui viennent d'être parsées[1]: cette notion de graphe est importantes pour certaines machines a états car ça permet de déduire des propriétés de l'algorithme comme par exemple prouver la terminaison.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll