Primeiramente, nossa implementação do Observer terá 2 interfaces:

-        IObserver, implementada por todos os observadores que devem responder às mudanças no Sujeito

-        ISubject. Implementada pelo Sujeito Observado.

Trabalhar com essas interfaces simplifica muito a manutenção do código graças ao princípio da substituição de Liskov como veremos no final do artigo. Por enquanto, continuaremos com a implementação.

Nossa interface IObserver terá somente o método Atualizar(direcao:String):void. Esse é o único método que todos os outros observadores do meu sistema deverão ter. "E o que ele faz, Tiago?" Esse é o método que atualiza a direção do Observador baseado na direção que o Sujeito Observado tomar em um dado instante.

package Observer

{
	public interface IObserver
	{
		function Atualizar(direcao:String):void;
	}
}

Nossos Sujeitos, porém, terão outras funcionalidades: ISubject deverá ter um método para registrar novos observadores e um outro para notificá-los sobre as mudanças de direção.

package Observer

{
	import Observer.IObserver;

	public interface ISubject
	{
		function RegistrarObservador(observador:IObserver):void;
		function NotificarObservador():void;
	}
}

Esse é nosso jato, um sujeito observado pelos mísseis teleguiados. Notem que, por ser um sujeito, ele obrigatoriamente deve implementar a interface ISubject que criamos e, consequentemente, também seus métodos.

package Observer
{

	public class TJato implements ISubject
	{
		private var _observadores:Array;
		private var _direcao:String;

		public function TJato(direcao:String)
		{
		this._observadores = new Array();
		this._direcao = direcao;
		}

/***************************************************************

Adiciona um observador à coleção de observadores do sujeito  ...

... observado, para que ele possa notificá-los quando seu    ...

... estado mudar.

Por ser passado um objeto IObservador, TODA E QUALQUER...

... CLASSE pode se tornar um observador, desde que ...

... implemente a interface IObserver.

****************************************************************/

		public function RegistrarObservador(observador:IObserver):void
		{
			// Adiciono um observador à lista...
			this._observadores.push(observador);

			// ... e aviso a todo mundo quem foi registrado
			trace ("observador registrado: "+ observador);
		}

/***************************************************************

Varre a coleção de observadores, enviando à eles o novo estado.

... Utiliza a metodologia de empurrar dados observados.

****************************************************************/

		public function NotificarObservador():void
		{
			for(var i:int=0; i<this._observadores.length; i++)
			this._observadores[i].Atualizar(this._direcao);
		}

/***************************************************************

Retorna a direção para onde o Jato está voando

****************************************************************/

		public function RetornarDirecao():String
		{
			return this._direcao;
		}

/***************************************************************

Modifica a direção do Jato para uma nova direção

****************************************************************/

		public function ModificarDirecao(direcao:String):void
		{
			this._direcao=direcao;
			this.NotificarObservador();
		}
	}
}

O míssil terá somente esses 2 métodos. Note que eles são passivos, fazendo com que o funcionamento da classe dependenda exclusivamente do que é passado para ela.

package Observer
{

	public class TMissil implements IObserver
	{
		private var _direcao:String;

		public function TMissil(direcao:String)
		{
			this._direcao = direcao;
		}

/***************************************************************
Atualiza a direção para onde o Míssil está indo
****************************************************************/

		public function Atualizar(direcao:String):void
		{
			this._direcao = direcao;
		}

/***************************************************************
Retorna a direção para onde o Míssil está voando
****************************************************************/

		public function RetornarDirecao():String
		{
			return this._direcao;
		}
	}
}

Por fim, nossa classe principal, a TMain. Nela vamos realizar uma sequência de testes da funcionalidade do Observer.

package
{
	import flash.display.MovieClip;
	import Observer.IObserver;
	import Observer.ISubject;
	import Observer.TJato;
	import Observer.TMissil;
	import Observer.THelicoptero;

	public class TMain extends MovieClip
	{
		private var _jato:TJato;
		private var _missil1:TMissil;
		private var _missil2:TMissil;

		private var _helicoptero:THelicoptero;

		public function TMain()
		{
			//Inicia a direção do Jato e dos mísseis
			this._jato = new TJato("CIMA");
			this._missil1 = new TMissil("BAIXO");
			this._missil2 = new TMissil("PARADO");

			//Exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );

			//Como os mísseis devem observar o ...
			//... comportamento do jato,...
			//... eles são registrados como...
			//... observadores do jato.

			trace("---------------------------------------------------------");

			trace ("Registrando observadores");
			this._jato.RegistrarObservador(this._missil1);
			this._jato.RegistrarObservador(this._missil2);

			trace("---------------------------------------------------------");

			trace("modificando a direção do jato prá BAIXO");

			//Altera a direção do jato...
			this._jato.ModificarDirecao("BAIXO");

			//... e exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );

			/*
			Caso um desenvolvedor queira estender a ...
			... funcionalidade do programa ...
			... adicionando um novo tipo de
			... observador, ele pode fazê-lo sem   ...
			... a necessidade de mexer no código atual.
			Para isso, basta ...
			... adicionar sua nova classe ...
			... (THelicoptero, nesse caso), fazê-la ...
			... implementar a interface IObserver ...
			... e adicioná-lo à lista de ...
			... chamadas de objetos de perseguição.
			Veja no exemplo abaixo:
			*/

			trace("---------------------------------------------------------");
			trace("Registrando observadores");

			//O Helicóptero entra na perseguição ...
			this._helicoptero = new THelicoptero("LESTE");
			// ... sendo registrado também como observador
			this._jato.RegistrarObservador(this._helicoptero);

			trace("---------------------------------------------------------");

			//Altera a direção do jato...
			trace("modificando a direção do jato prá CIMA");
			this._jato.ModificarDirecao("CIMA");

			//... e exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );
			trace( "Direção do helicóptero: "
				  + this._helicoptero.RetornarDirecao() );
		}
	}
}

A saída desse código é a seguinte:

Direção do jato: CIMA
Direção do míssil 1: BAIXO
Direção do míssil 2: PARADO
---------------------------------------------------------
Registrando observadores
observador registrado: [object TMissil]
observador registrado: [object TMissil]
---------------------------------------------------------
modificando a direção do jato prá BAIXO
Direção do jato: BAIXO
Direção do míssil 1: BAIXO
Direção do míssil 2: BAIXO
---------------------------------------------------------
Registrando observadores
observador registrado: [object THelicoptero]
---------------------------------------------------------
modificando a direção do jato prá CIMA
Direção do jato: CIMA
Direção do míssil 1: CIMA
Direção do míssil 2: CIMA
Direção do helicóptero: CIMA

"Mas Tiago... Que helicóptero foi aquele ali no meio do código?" Ah é... enquanto estávamos fazendo o código, um outro desenvolvedor achou que helicópteros também são maneiros em perseguições e resolveu implementar um. Notaram como foi fácil adicioná-lo? Bastou que ele implementasse a IObserver que o princípio de Liskov tomou conta do resto. Caso eu queria mais de um Sujeito observado, minha nova classe implementará ISubject. Dessa forma, adicionar observadores ou sujeitos não implica em modificação alguma no código que já estava pronto.

“Outra coisa: e se um observador não quiser mais ser avisado sobre as mudanças do sujeito?” Para isso, a IObserver deverá ter um método removerObservador (observador:IObserver) : void; que vai varrer a lista de observadores e retirá-lo de lá. Isso fica como exercício para quem quiser continuar estudando o padrão.

Na próxima - e última - parte do artigo, disponibilizarei o projeto em AS3.0 e o diagrama de Classes disso tudo ae. Então, até a próxima!

Como falei com o Adauto, o Getting Real "é a coisa mais genial que eu li sobre gerência de projetos nos últimos 8 anos. É tão genial q chega a assustar." Ele vai diretamente contra tudo que a teoria nos empurra a fazer. O livro não passa de uma coletânea de práticas e estudos de caso do desenvolvimento dos produtos da 37signals, uma empresa de chicago que está no mercado desde 1999 fazendo software web. Por mais idiota que isso possa parecer (e, à primeira vista, ISSO PARECE), a 37signals produz softwares que, intencionalmente, FAZEM MENOS QUE A CONCORRÊNCIA. Antes de você desistir de continuar lendo saiba que são eles por trás do framework Ruby on Rails...

O próprio livro se define assim:

(Getting Real) é sobre pular todas as coisas que representam a realidade (cartas, gráficos, caixas, setas, esquemas, wireframes, etc.) e realmente construir a coisa real.

(Getting Real) é menos. Menos massa, menos software, menos funcionalidades, menos papéis, menos tudo que não é essencial (e a maioria do que você pensa ser essencial realmente não é).

(Getting Real) é permanecer pequeno e ser ágil.

(Getting Real) inicia com a construção da interface, ou seja, as telas reais que as pessoas irão utilizar. Começa com as experiências reais dos clientes, construindo a partir disso para trás. Dessa forma você obtém a interface adequada antes de obter um software errado.

"Ah Tiago. Essa parada ae é de desenvolvimento de sistemas na web. Eu só quero fazer um jogo. Prá quê você me manda ler isso?". Pois o Getting Real é justamente isso: cair na real, limpar tudo aquilo com o que você NÃO precisa gastar tempo agora e deixar para pensar no futuro. É sobre não pensar agora em resolver um problema que ainda não é um problema. É sobre não perder incontáveis dias otimizando uma rotina que só vai precisar ser otimizada quando você tiver 500 usuários ao mesmo tempo. É sobre não inchar o seu design, enxugar seu escopo, fugir da febre dos padrões e fazer SOMENTE o necessário para que seu projeto funcione com a qualidade que ele exige no momento.  Essas dicas, apesar de voltadas para uma aplicação web, são absolutamente verdadeiras para diversos outros tipos de projetos. Além disso, sua idéia principal pode ser adotada em todo e qualquer tipo projeto, seja de software ou não. Vai depende somente da forma com que a empresa encara eles.

Falando em empresas, As desenvolvedoras de jogos online já utilizam tais conceitos há anos: lançam atualizações constantes para seus jogos, aumentando gradativamente sua complexidade, começando a subir uma escada lá debaixo no primeiro degrau. Além disso, fazem correções de bugs críticos em tempo real, horas após sua descoberta. No final, o produto cresce naturalmente e não só ao trocar de pele: você se preocupa com pequenos problemas por vez, faz pequenos designs por vez, implementa pequenas novidades  por vez e tira pequenas funcionalidades por vez, tudo constantemente, em pequenos períodos por vez.

O Getting Real vai muito além de qualquer livro de gerência de projetos. Ele é uma coletânea de dicas que se torna seu livro de cabeceira já nos primeiros 15 minutos de leitura, daqueles que você não vai deixar de mostrar para todo mundo. E não tem essa de desculpa para não ler: ele é fácil, rápido, direto, tem versão em português muito bem traduzida e, ainda por cima, gratuita para ler na net. Tá esperando o quê para Cair na Real também?

O diagrama é simples, não há muito o que explicar: ele traz em colchetes os eventos que disparam a troca de estado, indicada pela seta. O início é o círculo preto e, o fim,  o branco com o centro preto (também auto-explicativo).

Diagrama de Transição de Estados

"E qual é a vantagem dele, Tiago?" A vantagem é que, ao ver todo o funcionamento dos estados em uma única imagem, temos uma visão muito maior da sua lógica e podemos apontar erros. Identificamos, por exemplo, um "sumidouro": o estado TMarioInvencivel não muda para outro estado, sendo impossível a continuação da lógica após ele. Seguindo a lógica do jogo, deveríamos colocar um timer nele para controlasse quanto tempo podemos ficar invencíveis.Viu? Graças ao diagrama identificamos facilmente um beco sem saída na nossa lógica.

"Tá... mas e o TMarioFlorDeFogo?" Então... colocá-lo no diagrama é um exercício para vocês .

ps.: Desculpem pelo atraso na publicação do artigo, mas as coisas apertaram pro meu lado _ _'

Antes de continuarem lendo, recomendo que dêem uma parada no artigo sobre o Princípio da Substituição de Liskov. Entender como podemos trocar uma classe mãe por uma filha (ou, no caso do State, uma Interface por uma Implementação) é quase todo o segredo por trás desse padrão de projetos e vai tornar muito maior o entendimento do que vem pela frente. E não se esqueçam de voltar para o State quando terminarem de ler sobre Liskov!

Para iniciar o State, comecemos encapsulando todos os métodos que identificamos no artigo anterior como alteradores de estados e propagar esses métodos para nossos estados.

"Não entendi nada, Tiago". É simples: colocando na interface os métodos em comum aos estados, farei com que cada um desses estados tenha obrigatoriamente aqueles métodos principais da lógica da máquina de estados. Falando neles, a lista compreende:

• PegarCogumelo()
• PegarEstrela()
• PegarFlorDeFogo()
• ReceberDano()

Nossa interface fica simples assim:

package Mario
{
	public interface IMario
	{
		function PegarCogumelo():IMario;
		function PegarEstrela():IMario;
		function PegarFlorDeFogo():IMario;
		function ReceberDano():IMario;
		function RetornarTipo():String;
	}
}

Vejam que todo método vai, obrigatoriamente, retornar um objeto IMario. Para debug, coloquei também um método extra, o “RetornarTipo()”. Ele pode ser chamado pelo código para ver em qual estado o Mario está naquele momento. Após a criação da interface, precisamos agora implementá-la, criando nossos estados. Para quem não se lembra, são:

• Mario
• Super Mario
• Mario Flor de Fogo
• Mario Invencível
• Mario Morto

Cada um desses estados é uma classe que implementa nossa interface IMario. Vamos então criar um? Prestem bastante atenção ao código:

package Mario
{
	import Mario.IMario;

	public class TMario implements IMario
	{

		public function TMario(){}

		public function PegarCogumelo():IMario
		{
			trace("-- Mario pega um cogumelo!" +
				"Agora ele é um Super Mario --");
			return new TSuperMario();
		}

		public function PegarEstrela():IMario
		{
			trace("-- Mario pega um starman!" +
				"Agora ele é um Mario Invencível --");
			return new TMarioInvencivel();
		}

		public function PegarFlorDeFogo():IMario
		{
			trace("-- Mario pega uma fire flower!" +
				"Agora ele é um Mario Flor de Fogo --");
			return new TMarioFlorDeFogo();
		}

		public function ReceberDano():IMario
		{
			trace("-- Mario encosta em um" +
				"inimigo e morre! --");
			return new TMarioMorto();
		}

		public function RetornarTipo():String
		{
			return "normal";
		}
	}
}

Notem que cada método que faz Mario mudar de Estado ou forma retorna seu novo Estado. Lembram da IMario com seus métodos que retornam objetos IMario? Então... Como os métodos nela tem que ser padrão para todos os estados mas são implementados de forma diferente nesses estados, utilizamos o tal Princípio da Substituição de Liskov (você leu, né?). Não entendeu? Bem,  quando nosso método retorna um IMario estamos dizendo para o compilador que o método vai retornar um objeto IMario ou um objeto que implemente IMario. Utilizando esse princípio, os métodos de mudança de estado poderão retornar qualquer estado que implemente IMario.

Interessante, não? Nosso código fica extremamente manutenível, tornando a adição de um novo estado uma coisa muito fácil. Compare agora com o funcionamento de TSuperMario:

package Mario
{
	import Mario.IMario;

	public class TSuperMario implements IMario
	{
		public function TSuperMario(){}

		public function PegarCogumelo():IMario
		{
			trace("-- Super Mario pega um cogumelo," +
				"mas nada acontece com ele --");
			return this;
		}

		public function PegarFlorDeFogo():IMario
		{
			trace("-- Mario pega uma fire flower!" +
			        "Agora ele é um Mario Flor de Fogo --");
			return new TMarioFlorDeFogo();
		}

		public function PegarEstrela():IMario
		{
			trace("-- Super Mario pega uma estrela!" +
				"Agora ele é Mario Invencível --");
			return new TMarioInvencivel();
		}

		public function ReceberDano():IMario
		{
			trace("-- Super Mario encosta em um inimigo." +
				"Ele volta a ser Mario --");
			return new TMario();
		}

		public function RetornarTipo():String
		{
			return "super";
		}
	}
}

Viram? Alguns métodos (como PegarCogumelo() e ReceberDano() ), nesse estado, retornam objetos diferentes, mas que implementam a mesma interface! Temos até um return this significando que o objeto não mudou de estado naquele método, mas como this também implementa a interface IMario, não dá problema algum. Começaram a ver a tabela da 1ª parte sendo implementada, não?

Para poupar espaço, não colocarei o código de todos os estados. Basta ter a implementação de um para entendermos como as coisas estão acontecendo. Além disso, o projeto em Actionscript 3.0 está disponível para download no final do artigo. O importante agora é nos focarmos na nossa classe principal, a TMain.

public class TMain extends MovieClip
	{
		public function TMain()
		{
			var mario:IMario;

			//Qual é o estado inicial do Mario? ...
			// ... troque-o e veja.que o programa...
			// ... se comportará de forma...
			// ... completamente diferente!
			mario = new TMario();

			// O Mario (ainda no estado anterior)
			// pega um cogumelo
			mario = mario.PegarCogumelo();

			// O Mario (ainda no estado anterior) ...
			//  ... recebe dano
			mario = mario.ReceberDano();

			// O Mario (ainda no estado anterior) ...
			//  ... pega outro cogumelo
			mario = mario.PegarCogumelo();

			// O Mario (ainda no estado anterior) ...
			//  ...  pega uma Fire Flower
			mario = mario.PegarFlorDeFogo();

			// O Mario (ainda no estado anterior) ...
			//  ...  pega um starman
			mario = mario.PegarEstrela();

			// O Mario (ainda no estado anterior) ...
			//  ...  encosta em um inimigo
			mario = mario.ReceberDano();

			// O Mario (ainda no estado anterior) ...
			//  ...  encosta em um inimigo
			mario = mario.ReceberDano();

			// O Mario (ainda no estado anterior) ...
			//  ...  encosta em um inimigo
			mario = mario.ReceberDano();

			trace("-- No final, o Mario é um mario "
     				 + mario.RetornarTipo() +" --");
		}
	}
}

Na nossa main, basta criar um objeto do tipo inicial (no exemplo acima comecei o "jogo" como TMario) e, no decorrer do percurso, realizar as chamadas aos métodos respectivos. O código acima retorna para mim:

-- Mario pega um cogumelo! Agora ele é um Super Mario --
-- Super Mario encosta em um inimigo. Ele volta a ser Mario --
-- Mario pega um cogumelo! Agora ele é um Super Mario --
-- Mario pega uma fire flower! Agora ele é um Mario Flor de Fogo --
-- Mario pega um starman! Agora ele é um Mario Invencível --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- No final, o Mario é um mario invencível --

"Tá Tiago, esse trabalho todo prá q?" Esse trabalho todo traz os seguintes benefícios:

1. O código fica muito mais simples de entender sem ifs e cases aninhados uns dentro dos outros.
2. Simplifica a adição de um novo estado simplesmente fazendo com que ele implemente a interface base.
3. Modifica o funcionamento do sistema sem que haja a necessidade de prévia programação.

"Não entendi a 3a coisa da lista, Tiago. Como assim 'modifica o funcionamento'?" Se você trocaro estado inicial ou a chamada a um método, toda a linha de funcionamento do programa poderá ser modificada com o mínimo esforço. Olha o que acontece, por exemplo, se eu não quiser que o Mario pegue a estrela:

-- Mario pega um cogumelo! Agora ele é um Super Mario --
-- Super Mario encosta em um inimigo. Ele volta a ser Mario --
-- Mario pega um cogumelo! Agora ele é um Super Mario --
-- Mario pega uma fire flower! Agora ele é um Mario Flor de Fogo --
-- Mario encosta em um inimigo! Ele vira um Mario --
-- Mario encosta em um inimigo e morre! --
-- No final, o Mario é um mario morto --

Ou então, mais engraçado, caso ele comece já invencível:

-- Mario Invencível pega um cogumelo! Ele continua sendo o Mario Invencível--
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- Mario Invencível pega um cogumelo! Ele continua sendo o Mario Invencível--
-- Mario pega uma fire flower! Ele continua sendo o Mario Invencível --
-- Mario Invencível pega uma estrela, mas nada acontece com ele --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- Mario Invencível encosta em um inimigo, mas nada acontece com ele --
-- No final, o Mario é um mario invencível --

Como podemos ver, nosso "jogo" está flexível para qualquer possível acontecimento no decorrer de uma fase: basta que o evento esteja previamente mapeado pela nossa máquina de estados. Existem outras implementações do padrão State, sendo a mais comum o encapsulamento do estado dentro da classe TMario. Essa implementação é um pouco mais complexa, mas faz com que trabalhemos o tempo todo com um objeto do tipo TMario (e não uma interface IMario que, no decorrer da execução do programa, muda seu tipo dependendo do estado atual). No fim, o resultado é o mesmo.

Na próxima parte, vou mostrar para vocês como fica o Diagrama de Transição de Estados disso aí. E, para fechar, não se esqueçam de pegar o código em Actionscript 3.0 aqui:

[download id="2"]

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

Como pedido pelo Alexandre Ceni na 2a parte da micro-série sobre a UML, a 3a parte consiste em exemplos gráficos dos diagramas previamente citados.  Os diagramas que não fazem parte do Nuss... E agora?!? são da wikipedia. Essa página vai estar em constante modificação, pois vou substituindo os diagramas da wikipedia por aqueles que forem pintando nos artigos aqui. Não é foco do artigo  ensinar como desenvolver tais diagramas, até porque isso  é assunto para futuros artigos. Portanto, vamos a eles?

• Diagramas Estruturais (ou de estrutura)

Diagrama de Classes

Diagrama de Pacotes

Diagrama de Estrutura Composta

Diagrama de Objetos

Diagrama de Componentes

Diagrama de Instalação

• Diagramas Comportamentais (ou de comportamento)

Diagrama de Casos de Uso

Diagrama de Atividades

Diagrama de Transição de Estados

• Diagramas de Interação

Diagrama de Sequencia

Diagrama de Comunicação

Diagrama de Interação

Lembrem-se: saber entender os diagramas  é extremamente importante para o desenvolvimento de software: eles são uma forma de descrever exatamente o que você pretende e evitar problemas de comunicação entre os programadores e analistas.

“Tiago, você fala tanto sobre a UML, já falou de Casos de Uso, já mostrou diagramas e mais diagramas, mas até agora não disse: o que raios é a UML?”

UML é uma sigla para Unified Modelling Language. Em português, isso pode ser traduzido como Linguagem de Modelagem Unificada. Ou, simplificando, um conjunto de padrões de desenho para que você possa modelar um problema orientado a objetos, mostrá-lo a uma pessoa que entenda esses desenhos e ela entender aquilo da forma exata que você estava querendo que ela entendesse. Sabe quando um arquiteto faz uma planta de uma casa? Ou quando um roteirista escreve um roteiro? A idéia é exatamente a mesma, mas com os programas orientados a objetos.

“Orientado a Objetos... você já explicou isso aqui no nuss... Isso significa que a UML serve para o desenvolvimento de programas para computador, certo?” Tenho 2 respostas para tal pergunta:

• Sim. Como dito, a UML ajuda-nos a desenhar nossas relações orientadas a objetos. Como um programa OO é um problema orientado a objetos, ela serve para tal.
• Não. Como dito, a UML ajuda-nos a desenhar nossas relações orientadas a objetos. Como qualquer problema do nosso dia-a-dia pode ser organizado segundo a ótica da Orientação a Objetos, ela serve para muito mais que só modelar programas. Podemos, por exemplo, modelar a hierarquia de uma empresa, com seus departamentos, as funções dos funcionários e até mesmo a burocracia dos processos, chegando ao extremo de mapear até mesmo quem está trabalhando demais (ou de menos).

“Nossa, agora estou surpreso. Nunca pensei nessa possibilidade”. Sim, ela existe, porém é muito pouco usada. Eu já cheguei a explicar o problema de alguns relatórios em um departamento público com diagramas UML, mas para esses fins nunca cheguei a usar muito além disso.

“Isso significa que podemos utilizá-la para desenhar nossos problemas, independente de serem programas de computador ou não. Legal. Mas ela é usada mais no desenvolvimento de programas, como jogos de computador. Certo?” Exato. Com a UML, nós desenhamos todo o funcionamento do nosso, por exemplo, jogo. É com ela que eu anoto as características de um personagem, o que ele tem de itens, como são esses itens, como ele reage com o mundo de jogo, o que acontece quando ele ataca ou é atacado, quando pega um item ou passa de fase. A UML está para o programa como uma planta está para uma casa ou o roteiro está para um filme.

“Aaaaahhh. Acho que agora estou entendendo. Eu desenho com a UML o meu programa antes que os programadores programem as minhas idéias, como o roteirista escreve o roteiro do filme antes dele ser gravado” Novamente, Sim e Não. A UML não dita como você realiza o seu projeto, só desenha o programa. Ou seja, ela é independente da metodologia do projeto. Essa tal “metodologia do projeto” é quem dita o que e quando fazer. Tem metodologias onde fazemos a modelagem antes, outras durante ou até depois a programação. Além disso, algumas têm ciclos repetidos e incrementais durante todo o desenvolvimento, outras fazem tudo antes e, a cada problema encontrado volta-se ao início para corrigir tudo. Não existe “a melhor metodologia”: cada uma tem seus prós e contras, sendo recomendada ou não dependendo do que você pretende fazer. Como pode-se ver, a UML é só uma ferramenta para auxiliar o desenvolvimento do programa, independente de como você pretende desenvolvê-lo.

“Nossa. Legal isso. Posso fazer meu jogo com uma metodologia que eu prefira e, mesmo assim, utilizar o que você ensina aqui no Nuss...” Além de ser poderosa e flexível, eu considero esse um dos maiores pontos de sucesso da UML.

“Como assim flexível, Tiago?”. Isso já é assunto para a próxima parte desse artigo, onde falarei dos diversos diagramas da UML.

"TÁ DE BRINCADEIRA, NÉ? MAS COMO PODE?!" Ouço essa frase no trabalho, enquanto um dos colegas sai da frente do PC que mostra a foto da Vera Fischer. "Aí Tiago, tenta também!", disseram. Assim começa a minha história com Akinator, o gênio da Internet.

Akinator é um gênio fictício da internet que tem a simples meta de descobrir todo e qualquer personagem ou pessoa na qual você está pensando. "PENSANDO?!?", você pergunta. "Sim, PENSANDO!" eu respondo. Ele não pergunta em quem você está pensando, você não escreve e, se não quiser, nem mesmo fala prá ninguém. Mesmo assim, as chances são de que o rapaz acerte. Para que Akinator descubra, basta que você responda a uma série de perguntas.

"Mas como isso é possível?" Para explicar o que está acontecendo, antes temos que entender o que é Inteligência Artificial e Sistema Especialista.

"Inteligência Artificial não é fazer com que o computador tenha ações próprias, Tiago?" Mais que isso: é fazer com que ele chegue o mais próximo do pensamento humano. Em um jogo de xadrez, é fazer com que o computador seja tão desafiador quanto um jogador profissional. Em um sistema de gestão de projetos, é avaliar seu progresso e identificar os pontos problemáticos, prevendo problemas e dando dicas sobre como evitá-los. Em uma geladeira inteligente é ver quais os alimentos você tem comprado e avisar da falta de cálcio, ferro ou fósforo na dieta da casa.

"Então eu entendi o que é Inteligência Artificial. E esses tais Sistemas Especialistas?" Esses sistemas compreendem uma parte específica da Inteligência Artificial que, desde meados dos anos 70, se destacam no que diz respeito a seu foco: o sistema é capaz de aprender com seus erros e acertos, sendo alimentado pelos usuários para saber cada vez mais sobre determinado assunto. Quanto mais o tempo passa, maior é o banco de dados sobre o problema e mais o sistema está treinado na solução desse problema. Consequentemente, menos ele erra.

"Então o Akinator sabe cada vez mais sobre as características de cada vez mais personagens?" Sim, exatamente isso.  Na minha primeira vez jogando, por exemplo, ele fez uma sequencia de perguntas que, entre várias, incluia:

• Seu personagem é mulher? NÃO
• Seu personagem é brasileiro? NÃO
• Seu personagem é o principal da série onde aparece? SIM
• Seu personagem luta? SIM
• Seu personagem tem poderes especiais? SIM
• Seu personagem usa capa? SIM
• Seu personagem voa? SIM
• Seu personagem é real? NÃO
• Seu personagem veste azul e vermelho? SIM
• Seu personagem já esteve no espaço? SIM

Alguém aí sabe qual era o personagem, não? Se você, como o Akinator, disse Superman, parabéns: vocês usaram a mesma lógica para chegar ao resultado. Esse resultado, porém, foi ERRADO: eu pensei no Mario. Aí entra a alimentação do usuário: como ele errou, me permitiu ligar essa sequencia de perguntas a um novo personagem, (nesse caso ao Mario). Eu poderia até adicionar novas perguntas para o personagem caso eu quisesse. Foi o que eu fiz, por exemplo, com o Alien (do Alien vs Predador, lembram?): "Seu personagem possui alguma característica ácida?".

É baseado nessas perguntas que o Akinator responde: ele vai filtrando, filtrando e filtrando as suas respostas até que ache ter encontrado o personagem que você quer. Como exemplo, simulemos a sequencia de perguntas anterior com os seguinte banco de dados: Naruto, Xuxa, Mario, Pelé, Vera Fischer, Superman, Tiririca, Snake, Alien e Sonia Abrão.

• Seu personagem é mulher? NÃO

Saem das possibilidades Xuxa, Vera Fischer e Sonia Abrão.

• Seu personagem é brasileiro? NÃO

Saem agora Pelé e Tiririca.

• Seu personagem é o principal da série onde aparece? SIM

Continuam Mario, Superman, Snake e Alien.

• Seu personagem luta? SIM

Continuam Mario, Superman, Snake e Alien.

• Seu personagem tem poderes especiais? SIM

Mario voa, pula muito alto e usa vários power ups. Alien tem velocidade e força descomunais, além de sangue ácido. Superman dispensa comentários. Daí sai Snake.

• Seu personagem usa capa? SIM

Opa, tchauzinho Alien.

• Seu personagem voa? SIM

Ficam Mario e Superman.

• Seu personagem é real? NÃO

Ficam Mario e Superman.

• Seu personagem veste azul e vermelho? SIM

Hahaha. Quando ele  fez essa pergunta eu já estava indignado. Tinha certeza que ele ia acertar... Ficam Mario e Superman.

• Seu personagem já esteve no espaço? SIM

Ficam Mario e Superman.

Como foi visto, o funcionamento é baseado em uma busca por SIM ou NÃO. O Akinator ainda dá a possibilidade de você responder que aquilo provavelmente acontece, que você não sabe responder aquela pergunta ou que dificilmente aquilo é verdadeiro. Essas respostas somam ou subtraem pontos que ajudam a selecionar um personagem. Além dessas respostas especiais, outros fatores podem influenciar a resposta do Akinator, como a popularidade do personagem baseado em acertos prévios e quantidade de buscas (se você tem 2 possibilidades, escolheria a que tem maior probabilidade de ser correta, não?), perguntas com respostas erradas/incertas/inconsistentes para a situação atual (o videogame que você tem hoje pode não ser mais o videogame que você tem amanhã) e até mesmo a inexistência do resultado (lembre-se: o sistema especialista é alimentado com o tempo). Da próxima vez que ele ficar em dúvida entre o Mario e o Superman ele irá provavelmente perguntar algo para diferenciar os dois, como Seu personagem é um herói da Liga da Justiça? Aí sim ele irá acertar

"Tiago é sinistro, ganhou do Akinator", disseram. Ganhei sim, a 1a vez... Ele pode até ter confundido o Mario com o Superman, mas soube muito bem quem é a Samus Aran .

Saiba mais sobre Sistemas Especialistas nela, a Wikipedia!

Versão em inglês do Akinator aqui.

Para fechar o artigo anterior, como foi prometido, segue abaixo o diagrama do padrão de projetos Decorator. Apesar da longa explicação e do funcionamento diferente, o diagrama é bem simples:

Diagrama do padrão de projetos Decorator

A única coisa diferente nesse diagrama é o fato de TDecoratorBonus possuir, além da herança de TArma,  o atributo _arma do tipo TArma, fazendo assim que surjam as 2 setas. Além disso, basta não se esquecer que TEfeito e TEncantamento têm, por herança de TDecoratorBonus, seus próprios atributos _arma

O código do padrão (Action Script 3.0 com projeto Flash CS3) pode ser encontrado aqui: [download id="1"]

Você e 4 amigos, uma esquadrilha de netherdrakes, helicópteros, grifos e hipogrifos, girando por Oshu’gun enquanto procuram o gigante comedor de dragões Durn the Hungerer. Apesar da ameaça, vocês estão confiantes em seu grupo. O entardecer de Nagrand mostra a silhueta do gigante no horizonte e vocês sabem que a hora chegou.

A luta foi perfeita: o gigante arrasou com o grupo nos 20s mais estilosos que qualquer monstro do World of Warcraft já viu. Depois de 15min de brigas sobre quem tem a culpa, alguém descobre que o grupo não estava tão preparado assim. Todos então resolvem melhorar seus equipamentos... Mas como?

Apresento-lhes a morte do grande gigante, o padrão Decorator.

Vários jogos permitem a seus jogadores um vasto leque de personalização. Eles permitem que configuremos os personagens para que eles sejam o mais parecido possível com a gente em muito mais que só altura e cor de cabelos. Tais jogos permitem que configuremos também a forma com que esse personagem reage ao mundo de jogo, definindo coisas como a velocidade, o tipo de magia que ele usa ou o quanto sustenta de dano. Alguns jogos permitem até que você configure os itens que eles usam. Assim é o World of Warcraft, a febre do momento no mundo dos RPGS massivos (os MMORPGS).

Para vencer os desafios no WoW, os jogadores podem utilizar encantamentos, gemas, itens e diversos efeitos diferentes para aumentar suas características. Se foi isso que faltou no grupo, é isso que daremos a ele.

Comecemos pegando uma das armas dos jogadores. Essa arma exemplo será a classe TArma abaixo:

package Efeitos
{
	public class TArma
	{
		protected var _nome:String; // Damos um nome qualquer e …
		protected var _efeito:String; // … um efeito…

		public function TArma()
		{
			// ... mas setamos para os valores normais ...
			// ... afinal de contas, a arma não tem nada de especial ...
			// ... ainda
			this._nome = "Arma sem Bônus";
			this._efeito = "";
		}

		public function retornaNome():String
		{ return this._nome; }

		public function retornaEfeito():String
		{ return this._efeito; }
	}
}

Essa arma é o que os personagens têm no momento e, como já sabemos, isso não é o suficiente. Que tal incluirmos esses tais efeitos e encantamentos? Assim estaríamos adicionando a força necessária que os personagens precisam, não Tiago? É só criar uns métodos retornaEncantamento() como você fez e pronto.

Não só poderíamos adicionar tais características como várias outras características à arma. O problema é o futuro: a cada vez que um ou vários novos bônus aparecessem no nosso jogo, fossem modificados ou simplesmente excluídos do jogo (o que acontece com muita frequência), teríamos que atualizar essa classe Tarma, bem como TODO O CÓDIGO fazendo as chamadas a esses bônus, no caso deles simplesmente não existirem mais . Isso a torna alvo de alterações cíclicas, o que é longe de ser legal. A idéia aqui é encapsular essas alterações, aplicando-as como um skin ou tema à arma.

Para conseguirmos tal estrutura, usaremos o padrão Decorator: iremos “enfeitar” a arma com quantos bônus especiais precisarmos, aproveitando que ela já possui algo engatilhado para isso (afinal de contas, o método retornaEfeito() não está lá à toa) . Para isso, precisamos inicialmente criar a classe TDecoratorBonus:

package Efeitos
{
	//import Status.TStatus;

	public class TDecoratorBonus extends TArma
	{
		protected var _arma:TArma; // O Decorador possui uma instância de TArma.

		/***************************************************************
		Construtor da classe. Tem os atributos da TArma a ser decorada ...
		... por ser um tipo de arma.
		****************************************************************/
		public function TDecoratorBonus()
		{
			this._nome = "sem nome";
			this._efeito="";
		}
		/***************************************************************
		Esse método sobrescreve (overrides) o método retornaNome() da ...
		... classe TArma.
		****************************************************************/
		public override function retornaNome():String
		{ return this._nome; }
	}
}

Essa classe é o coração do nosso decorador: ela é a responsável pela estrutura de encapsulamento dos diversos efeitos. A principal estrela dessa clase é, sem dúvidas, o atributo protected var _arma:TArma. Sua função é guardar a camada de efeitos no caso dessa camada ser envolvida por outra camada. Não entendi nada, Tiago.Como assim camada envolvida por outra camada? Bom, se você pensar bem, estou falando de camadas como aquelas bonecas russas chamadas matrioshka que guardam outras bonecas idênticas dentro: essa instância seria uma "âncora" para que pudéssemos ir para a "boneca de dentro". Essa boneca de dentro, por sua vez, também tem sua boneca de dentro até o ponto em que não haja mais bonecas dentro.

Cada uma dessas bonecas é, no nosso exemplo, uma das camadas de bônus do padrão decorador, como a classe abaixo:

package Efeitos
{
	public class TEfeito extends TDecoratorBonus
	{

		/***************************************************************
		Construtor da classe recebe um objeto TArma. Ele é jogado para ...
		... a instância this._arma, encapsulando assim mais um nível para ...
		... a recursividade do padrão.
		****************************************************************/
		public function TEfeito(arma:TArma)
		{
			//Os seguintes atributos vieram por herança de TDecoratorBonus;
			this._arma = arma;
			this._efeito = "+10";
		}

		/***************************************************************
		Método que sobrescreve o retornaEfeito da classe TDecoratorBonus, ...
		... chamando ele próprio na instância this._arma da classe. Dessa ...
		... forma, o método inicia uma cadeia de chamadas que termina ...
		... na classe mais interna, a que não possui uma instância de ...
		... _arma.
		****************************************************************/
		public override function retornaEfeito():String
		{
			// Por ser um padrão de recursividade, é obrigatório que...
			// ... chamemos this._arma.retornaEfeito(). Só assim o ...
			// ... método continuará chamando os efeitos encapsulados.
			return (this._efeito + " " + this._arma.retornaEfeito());
		}
	}
}

Para fazer as camadas de bônus funcionarem, entra em ação uma coisa chamada recursividade: de forma simplificada (e, quem sabe, um dia eu escreva de forma completa), recursividade é a capacidade de um método ou função chamar a si mesma por várias vezes, retornando resultados para ela própria. Por enquanto, basta saber que o método retornaEfeito() é recursivo por chamae retornaEfeito() novamente, mas agora na camada de dentro (que, como já sabemos, é o atributo this._arma). A camada interna, por sua vez, chama retornaEfeito() de sua this._arma, que chama retornaEfeito() de sua this._arma, que chama retornaEfeito() de sua... Isso só acaba quando chegamos na arma inicial, a TArma, cujo método retornaEfeito() não chama outro retornaEfeito() e sim, exibe seu this._efeito.

Nesse momento, cada retornaEfeito() chamado retorna seu this._efeito para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna... O fim desse ciclo se dá quando não houver mais retornos a chamadas a retornaEfeito(), o que no nosso exemplo acontece na classe TMain mais à frente.

Essa estrutura fica assim:

Camadas

Com o padrão conseguimos criar uma arma genérica que possui ao seu redor várias camadas de efeitos e que funciona do exato mesmo jeito que uma arma que não possui efeito algum. Além disso, podemos ter diferentes tipos de efeitos, cada um implementado por uma classe diferente. Vou criar agora um TEncantamento:

package Efeitos
{
	import Efeitos.TDecoratorBonus;

	public class TEncantamento extends TDecoratorBonus
	{

		public function TEncantamento(arma:TArma)
		{
			this._arma = arma;
			this._efeito = "Mongoose";
		}

		public override function retornaEfeito():String
		{
			return (this._arma.retornaEfeito() + " " + this._efeito);
		}
	}
}

Por fim, basta decorarmos a arma:

package
{
	import flash.display.MovieClip;
	import Efeitos.TDecoratorBonus;
	import Efeitos.TEncantamento;
	import Efeitos.TEfeito;
	import Efeitos.TArma;

	public class TMain extends MovieClip
	{
		public function TMain()
		{
			// Criamos uma arma qualquer ...
			var arma = new TArma();

			trace ("Antes dos efeitos"); // ... e exibimos seus bônus iniciais.
			trace ( arma.retornaEfeito() );
			trace ();
			trace("---------------------------------------");
			trace ();

			// Agora o padrão entra em ação. Criamos um efeito TEfeito que ...
			// encapsula a arma atual e é passado para ela mesma. Agora ...
			// arma tem dentro de si um TEfeito.
			// Efeito +10
			arma = new TEfeito(arma);

			// Pegamos agora a TEfeito e jogamos dentro de TEncantamento, ...
			// ... passando novamente para a arma. Agora ela tem um ...
			// TEncantamento que tem um TEfeito.
			arma = new TEncantamento(arma);

			// ... que vai dentro de mais um TEfeito ...
			arma = new TEfeito(arma);

			// ... que termina dentro de outro TEfeito
			arma = new TEfeito(arma);

			// Ao realizarmos a chamada a arma.retornaEfeito(), o próprio ...
			// ... método se encarrega de chamar retornaEfeito() das ...
			// ... instâncias encapsuladas, de forma recursiva.

			trace ( arma.retornaEfeito() );
		}
	}
}

No próximo artigo eu disponibilizo o projeto (Flash CS3) e os arquivos das classes (Action Script 3.0). Falo também do diagrama de classes dessa brincadeira toda. Até lá, caso alguém tenha qualquer dúvida, basta perguntar.

No final de uma longa batalha, O gigante finalmente tomba. Seu colossal corpo vai agora servir de alimento para as criaturas que das quais sua linhagem alimentou-se durante eras. Os heróis retornam para suas montarias e tudo volta a ser tranqüilo, graças ao padrão Decorator.