Dando continuidade a primeira parte dessa série sobre FSM, agora iremos por um pouco a mão na massa!
Show me the Code!
Para por a mão na massa primeiro precisaremos de um projeto e um problema, assim mostraremos uma solução!
O projeto que será apresentado se chama “PokeCatcher State Machine” desenvolveremos um software que irá simular a captura de Pokémons de maneira iterativa, apresentando o State Machine como o meio para o controle das transações.
Utilizaremos inicialmente Python para codificar uma máquina de estado do zero, depois, utilizaremos o framework Spring StateMachine com Java (acho importante sabermos a base! antes de ir para uma abstração de um framework)
Como dito anteriormente precisamos de um problema. Mostraremos então como o código desse jogo poderia ser escrito, não de um modo errado, mas, imperativo e com diversos pontos a serem repensados e melhorados. Veja:
Ao ler o código, notamos uma quantidade considerável de whiles e uma tendência a processos encadeados. Um código dessa maneira, mostra o quão ele é inflexível, e a cada nó adicionado, sua complexidade subirá exponencialmente a ponto de sua manutenção se tornar inviável.
Nota-se que o código é de certa forma orientado a eventos, e que esses eventos são alinhados com um ‘estado’ atual do personagem, cada while representa um estado do jogo e cada if alinhado a ele demonstra a captura de uma ação e sua execução. Dessa maneira podemos mitigá-lo para uma implementação simples de State Machine.
Para iniciarmos a implementação, criaremos um diagrama, no qual, ficará nítido para nós os estados e os eventos que levam a sua mudança.
O diagrama nos dá uma visibilidade melhor do estado inicial, final e do comportamento esperado para cada ação. Com ele podemos iniciar nossa codificação.
O código a seguir mostra a definição dos enums States e Events, também criaremos um objeto Pokemon que será nosso personagem. Ele transacionará o estado da máquina — iniciando sempre pelo seu estado inicial determinado pelo diagrama.
Mapeado os objetos podemos de fato implementar nossas regras se baseando no fluxo de eventos, com isso teremos uma estrutura para receber nosso personagem e a ação desejada.
Para a máquina executar sua função utilizaremos instruções if/elif (em outras linguaguens poderiamos utilizar o switch) no ‘processador de evento’ para determinar a transação a ser executada dado o evento e o estado atual do personagem. Vejamos:
Nosso fluxo de processamento de eventos está pronto, com transações muito bem definidas. Dessa maneira temos uma implementação simples de State Machine.
A iteratividade com o usuário muda um pouco, para essa solução. O loop nos permite lidar com vários personagens — nota-se que agora teremos apenas um while com processos menos encadeados.
Esse exemplo simples de State Machine nos mostrou como podemos trabalhar com um flow de eventos muito bem descrito, sem muitos encadeamentos de chamadas e dependências de laços de iterações complexas.
Porém ainda não satisfeito com os elif’s apresentados pelo nosso ‘process_event’ iremos montar uma biblioteca de FSM e desacoplar ainda mais nosso código, deixando-o mais robusto e conciso.
Apresentamos nessa segunda parte uma simples implementação, mostrando a diferença de um estilo de código para um padrão de State Machine, na próxima iremos refatora-lo e construir uma biblioteca, além de demonstrar o uso com o Spring StateMachine. Não perca… See you
