Là c'est un peu facile comme cas d'utilisation: il faut que tu recopie une machine à états déjà faite qui marche et qui ne peut pas changée. Dans la vraie vie, ils y a des normes qui ont des machines à état buggées, et c'est marrant de voir comment les implémenteur se vautrent une fois qu'ils ont découvert que la machine à état ne peut pas marcher. Le problème, c'est que généralement, ils ne changent pas la structure de la machine à état.
Et surtout, le problème des machines à états dans les réseaux, c'est que tu ne sais pas quoi faire d'événements qui ne sont pas censés arriver, et donc tu n'a pas deux implémentations qui font la même chose. Les protocoles qui sont spécifiés par du code asynchrones ne permettent pas d'ambiguïtés.
[^] # Re:
Posté par Batchyx . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 4.
Là c'est un peu facile comme cas d'utilisation: il faut que tu recopie une machine à états déjà faite qui marche et qui ne peut pas changée. Dans la vraie vie, ils y a des normes qui ont des machines à état buggées, et c'est marrant de voir comment les implémenteur se vautrent une fois qu'ils ont découvert que la machine à état ne peut pas marcher. Le problème, c'est que généralement, ils ne changent pas la structure de la machine à état.
Et surtout, le problème des machines à états dans les réseaux, c'est que tu ne sais pas quoi faire d'événements qui ne sont pas censés arriver, et donc tu n'a pas deux implémentations qui font la même chose. Les protocoles qui sont spécifiés par du code asynchrones ne permettent pas d'ambiguïtés.