Prá começar, aí está o Diagrama de Classes:

Ele é simples como a estrutura do padrão: as classes que são observadoras implementam a interface IObserver, o sujeito observado implementa a ISubect que, por sua vez, tem um conjunto de IObservers.

Aqui você baixa o código do projeto CS3 em Actionscript 3.0  [download id="3"]

Até a próxima!

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á!

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.

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