Pense em um jogo onde o seu personagem muda de habilidades no decorrer da aventura. Não importa se pegando itens ou ganhando poderes especiais, o importante é que saibamos o quanto de trabalho isso dá para a programação. “Ué Tiago, não é só criar as classes de cada um desses poderes especiais e ir transformando o personagem em outro objeto?”

Na realidade, isso é só o início dos nossos problemas. Quer ver só: vamos pensar no Mario. Em um jogo clássico como o Super Mario Bros. ele tem as seguintes formas: Mario, Super Mario (quando pega um Super Mushroom), Mario Flor de Fogo (quando pega uma Fire Flower), Mario Invencível (quando pega um Starman) e, claro, Mario Morto, quando ele morre. Para que isso funcione, o Mario precisa de um conjunto de ações simples: Pegar Cogumelo, Pegar Starman, Pegar Fire Flower, e, como nem tudo é perfeito, ele também tem que poder, Encostar em um inimigo.

“E o que isso tem a ver?” Se você ainda não percebeu, cada um dessas formas do Mario tem o mesmo conjunto de ações: seja um Mario, um Mario Flor de Fogo ou qualquer outra forma de Mario, todos têm que poder encostar em um inimigo, pegar um cogumelo, um starman ou uma fire flower. O que muda é o comportamento daquela forma de Mario perante aquela ação. Não entendeu? Bom... enquanto Mario encosta em um inimigo e morre, Super Mario encosta em um inimigo e volta a ser Mario. A mesma ação (encostar em um inimigo) engatilha 2 ações diferentes (Virar Mario Morto e Virar Mario).

Mapeando todas essas relações entre as formas do Mario temos...

Na 1a coluna, temos os estados iniciais. A 1a linha tem as ações e o corpo da tabela é a forma que o Mario assume após aquele evento. Por exemplo, Mario pega um cogumelo e vira Super Mario. Esse mapeamento de troca de formas é o que chamamos de Máquina de Estados: ela indica quais formas aquele objeto tem (o que chamamos de estado), quais ações aquele estado pode realizar e qual novo estado ele vai assumir após realizar tal ação.

Quem joga os jogos do Mario sabe que, na realidade, o estado Mario Invencível depende do estado onde o Mario estava anteriormente. Então teríamos além de Mario Invencível, as formas Super Mario Invencível e Mario Flor de Fogo Invencível... Olhe como adicionar essa simples característica aumenta muito nossa complexidade: no nosso exemplo, temos 4 ações x 5 formas = 20 métodos a serem implementados. Aumentar 3 estados significaria passar para 4 ações x 7 formas = 28 métodos.

“Até aí tudo bem, Tiago!” Sim, mas o problema vem agora: também precisamos saber qual ação foi executada e em qual forma o Mario estava. Para fazer isso, precisaríamos de um conjunto imenso de testes aninhados que fariam, para cada ação:

Se o jogador pegou um Cogumelo:
    está na forma Mario, troque para a forma Super Mario
    está na forma Super Mario, mantenha-se como Super Mario;
    está na forma Fire Flower Mario, mantenha-se como Fire Flower Mario;
    está na forma Mario Invencível, mantenha-se como Mario Invencível;
    está na forma Mario Morto, mantenha-se como Mario Morto;

... muito trabalho, né não? Além disso, para cada uma dessas novas formas, teríamos que ir nesse conjunto de testes aninhados para adicionar as novas regras. Estruturas mais complexas seriam tão trabalhosas de gerenciar que se tornariam inviáveis. Essa complexidade crescente é das grandes vilãs quando trabalhamos com estados: a cada estado adicionado temos que mapear todas as relações entre ele e os estados já existentes programando suas relações.

Para resolver esse problema de manutenibilidade, utilizamos o Padrão de Projetos State (ou “Estado”). No próximo artigo implementaremos essa Máquina de Estados do Mario. Então, até lá!

Imagens de http://mario.wikia.com