Ótimo passo da Adobe que tem por padrão publicar artigos de altíssimo nível. O portal promete derrubar os mitos por trás da programação em actionscript e trazer uma nova era para o desenvolvimento nas ferramentas, o que torna-o extremamente recomendado tanto para quem já tem experiência quanto para quem está perdido e não sabe por onde começar.

Valeu ao pessoal da Loodo pela dica no twitter

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!

Apesar de simples, isso é tudo que você precisa saber antes de ler sobre o padrão Observer (Observador).

No exemplo anterior temos todas as entidades do padrão Observer bem definidas. Seu filho é o Observador, aquele que está ali ansioso, esperando seu aviso de quando é que a tal surpresa vai chegar. Já você é o que chamamos de Sujeito Observado, quem detém a informação da surpresa, a função de identificar quando ela já pode ser mostrada e avisar a seu observador que chegou a hora dele vê-la.

Como podemos ver, os Observadores se registram no Sujeito Observado, esperando só o momento de reagir às mudanças no Sujeito. Outro exemplo claro da lógica do padrão Observador é assinar os feeds de um site ou uma revista qualquer: todos os assinantes são avisados quando os novos artigos são publicados, bastando esperar para que isso aconteça.

O funcionamento do padrão é simples, mas os ganhos com ele são muito grandes. Com ele você consegue poupar o processador de inúmeras requisições frustradas (como todos os “Já chegou?” antes de realmente ter chegado), deixando para avisar a todos aqueles que se registraram como observadores quando o evento esperado ocorrer. Até que isso ocorra, eles ficam lá, quietinhos, sem encher o saco de ninguém...

O padrão é tão importante que, em muitos casos, seu uso é completamente transparente, sendo já embutido aos frameworks. No Actionscript 3.0, por exemplo, quando utilizamos um eventListerner, não estamos fazendo nada mais que utilizar o padrão. A seguinte linha...

_botao.addEventListener(MouseEvent.CLICK, aoClicar);

... na realidade, está registrando o objeto _botao como observador dos eventos do AS3.0. Quando o evento MouseEvent.CLICK ocorrer, _botao engatilhará o método aoClicar.

“Ta Tiago, mas o que os mísseis teleguiados tem a ver com isso?” Como não poderia ser diferente, na próxima parte do artigo vocês terão um exemplo de como implementar o Observer, brincando com esses mísseis teleguiado. Até lá!

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"]

Antes de continuarmos pelos padrões de projeto, acho importante ter aqui uma explicação sobre o Princípio da Substituição de Liskov. Ele é comum nas boas práticas de programação orientada a objetos e seus conceitos aparecem muito ao utilizar diversos padrões de projeto, principalmente no uso de Interfaces em padrões como o State (estado), o Strategy (Estratégia) ou os diversos tipos de Factories (Fábricas). Apesar de sua popularidade, ainda sim costuma dar um nó na cabeça de quem está começando.

Historicamente falando, O princípio foi introduzido em 1993 (muito recente, como podem ver) por Barbara Liskov e Jeannette Wing no artigo Family Values: A Behavioral Notion of Subtyping. Segundo ele:

Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

“Mas hein?!?” Apesar de parecer complicado, não é. Traduzindo isso para uma linguagem mais simples:

Se você pode chamar um método q de uma classe TMae, pode também chamar o método q de uma classe TFilha com herança de TMae.

“Bom, melhorou bastante. Mas você não pode explicar melhor não, Tiago?” Se uma classe herda de outra classe, cria-se a relação de “é um”. Explicar isso à fundo é material para um outro artigo, mas basta dizer que quando a classe TFilha herdou os métodos de TMae, ela passou a ser uma TMae estendida, melhorada (daí algumas linguagens utilizarem a palavra extends para definir herança): ela tem TUDO que uma TMae tem, além das coisas que só TFilha tem.

Se TFilha tem tudo que a TMae tem, as chamadas por TMae podem receber uma TFilha sem o menor problema. Entendamos o código abaixo:

Primeiro criamos uma classe TMae:

package Classes
{
	public class TMae
	{
		public function TMae()
		{
		}

		public function Voce(): void
		{
			trace ("Eu sou uma TMae");
		}
	}
}

Como TMae precisa de uma filha, vamos criá-la herdando de sua mãe:

package Classes
{
	import Classes.TMae;

	public class TFilha extends TMae
	{
		public function TFilha(): void
		{
			super(); // Chama o construtor da classe TMae
  		}

		public override function Voce():void
		{
			trace ("Eu sou uma TFilha");
		}

		public function Mae():void
		{
			// chama o método Voce() da classe mãe
			super.Voce();
		}
	}
}

Vale lembrar que TFilha pode ter seus extras, como fiz com o método Mae(), que exibe a mãe de filha, o método Voce() de super. Para colocar isso tudo para funcionar, precisamos da classe TMain:

package
{
	import flash.display.MovieClip;
	import Classes.TMae;
	import Classes.TFilha;

	public class TMain extends MovieClip
	{
		public function TMain(): void
		{
			var mae: TMae = new TMae();
			var filha: TFilha = new TFilha();

			trace ("======= MAE =======");
			this.testarLiskov(mae);

			trace ("======= FILHA =======");
			this.testarLiskov(filha);

			trace ("======= MAE DA FILHA =======");
			filha.Mae();

			//trace ("======= MAE DA MAE? =======");
			//mae.Mae();
		}

		public function testarLiskov(obj:TMae)
		{
			obj.Voce();
		}
	}
}

A saída disso é a seguinte:

	======= MAE =======
	Eu sou uma TMae
	======= FILHA =======
	Eu sou uma TFilha
	======= MAE DA FILHA =======
	Eu sou uma TMae

Para terminar, lembrem-se que o Princípio da Substituição de Liskov não é comutativo. Ou seja: podemos trocar a TMae por uma TFilha, mas não uma TFilha por uma TMae. Se TFilha pode possuir mais métodos e atributos  que TMae, não temos como chamá-los diretamente por TMae. Para confirmar, basta descomentar a linha mae.Mae() e ver que o compilador não consegue encontrar o método Mae() em TMae (claro, ele é de TFilha!).

Saiba mais sobre o Princípio na Wikipédia.

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.

Essa é uma dica rápida para quem quer desenvolver para um videogame de última geração. No ByteArray você o WiiFlash, uma biblioteca em Action Script 3.0 que liga faz a comunicação entre seu Wiimote e o Adobe Flash, Flex ou Air.

Graças à comunicação do Wiimote (e seus metaperiféricos Nunchuk, Wii Balance Board...),  basta reconhecê-lo como um dispositivo Bluetooth no seu PC, rodar o WiiFlash Server e pronto, começar a desenvolver. O problema maior aqui é a documentação toda em inglês, o que pode afastar aqueles que têm dificuldades na língua... Vejam como uma ótima oportunidade para começar a estudá-la!

Aqui você baixa o Wiiflash com o código fonte, caso queira modificá-lo ou até mesmo adicionar novas funcionalidades à biblioteca.  Na página do Google Project Hosting do WiiFlash você encontra exemplos de como é simples trabalhar com o joystick. Falando nele, esse link explica como fazer seu PC reconhecê-lo, podendo trabalhar com mais de 1 ao mesmo tempo.

Esse vídeo em inglês ensina o necessário para que você inicie seu desenvolvimento. Só fique de olho pois ele foi feito em um Mac... Ou seja: nada de Windows Explorer ou Menu Iniciar.

O site wiiplayable possui uma grande lista de jogos em Flash que podem ser jogados diretamente pelo Wii através do Opera.

Abaixo, uma lista de exemplos de uso do wiiflash:

• Simulação de Vôo
• Wiispray
• Wiirimbau

Vocês vão notar que eu deixei até as rotinas de debug (como o trace quando se passa o cursor sobre a bola) dentro da estrutura MVC. Além disso, vão também ver que cada camada do nosso Jogo está num pacote homônimo. Conseqüentemente, a estrutura de pastas também reflete essa lógica, organizando de forma muito melhor os arquivos.

Os comentários não estão muito explicados, mas quem tiver ainda alguma dúvida DEVE recorrer às partes 1 e 2 do artigo sobre o MVC, agora vendo como tudo acontece no código.

Bom, espero que isso ajude a vocês (especialmente ao Aryel que pediu o código). Qualquer dúvida, é só comentar!
Até a próxima!