Re: Machine à états ?

Je comprends le rapprochement avec une machine à états mais ça ne m'a pas l'air d'en être une du tout.

J'avoue, c'est le nom le plus proche que j'ai trouvé pour ce design pattern que j'utilise sans en connaître le nom.

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.

Ici la "transition" c'est le retour de la fonction.

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.

En théorie oui, en pratique, je trouve toujours plus simple de donner la possibilité à l'état d'effectuer lui même la transition.

Par exemple, en gamedev, j'utilise pas mal les "Stack Based State Machine", l'état retourne soit :

• rien, on continu d'exécuter cet état (via OnUpdate)
• Push new state, on appelle le OnPaused de l'état en court puis le OnEnter de l'état suivant
• Pop state, on appelle le OnExit de l'état en court, puis le OnResume de l'état précédent

C'est pratique pour implémenter les menus, la mise en pause, le game over, etc...

Optional[State[HTTPContext]]
C'est pas un peu lourd à l'usage ça ?

En Python c'est strictement équivalent à State[HTTPContext] | None, le None représentant la fin de l'exécution de la State Machine.

J'ai une dernière question, comment tu récupère ton résultat à la fin ?

CF l'exemple avec la suite de Syracuse, c'est via la propriété context de l'objet StateMachine. Dans un langage immutable, on aurait plutôt :

while state is not None:
 state, context = state.run(context)

C'est ce qu'on retrouve notamment avec les GenServer en Erlang/Elixir.

Ici, le contexte ce sont les données en entrée ET en sortie de l'algorithme.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg