Ó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

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!

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

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!

Agora que todos já sabem como funciona o MVC, vou continuar com a 2a e última parte do artigo. Hoje vou mostrar os pontos positivos e negativos da implantação da arquitetura, além de finalmente mostrar o que isso tudo tem a ver com o Linkage.

Pontos positivos:

• Abstração e desacoplamento das camadas

Quando estamos programando a interface do problema, não nos preocupamos com a programação da lógica dele, somente com o que vai e o que vem dela. Dessa forma, podemos facilmente simular todo o funcionamento da lógica do programa com uma classe de testes que simula o funcionamento da lógica. Esse é o conceito de caixa preta, importantíssimo para o bom funcionamento de um software.

• Facilidade de manutenção

Graças a esse desacoplamento, é muito mais fácil realizar a manutenção de um programa desses. Se for um problema visual, você vai à camada responsável pelo visual do programa e pronto, corrige. Se for um problema de lógica, é na lógica que você buscará a solução. Além disso, graças ao padrão Controlador (Controller), você pode apagar toda uma janela sem perder nada de sua implementação.

Quem está acostumado a adicionar código em um botão sabe exatamente o trabalho que isso ta poupando, mas para quem não está, aí vai um exemplo. Sabe esse Mario 2 que refizeram em 3D pro Nintendo DS? Se eles não usaram o MVC para fazer o original, perderam uma gigantesca parte da lógica do programa só por trocar a interface. Em compensação, usando o MVC de forma correta eles trocariam toda a interface sem mexer em 1 linha da lógica.

• Possibilidade de Expansão

A estrutura de camadas proposta no MVC pode (e deve) ser expandida: criar mais camadas aumenta a coesão e diminui o acoplamento, organizando melhor o seu código. No jogo, por exemplo, além da Lógica e da Interface, temos a camada de Comunicação (rede) e a camada de Armazenamento (Banco de Dados), além das camadas entre elas. Um outro jogo pode, por exemplo, ter uma camada de IA, uma camada de hardware e uma camada de comunicação com outro jogo. O nosso, inicialmente, está assim:

As camadas se comunicam através de Indireções, como os já citados padrões Controlador, Proxy e DBBroker. Isso claro, pode mudar durante a análise de Casos de Uso mais avançados, mas inicialmente, essa é a idéia. Além disso, o funcionamento desses padrões vai ficar para futuros artigos.

• Facilidade de realização de testes

Com o programa modularizado, podemos criar classes de teste que rodam nosso programa à exaustão, podendo encontrar bugs estatisticamente impossíveis de encontrarmos. Mas sabe qual é o melhor? Você pode testar isso tudo sem ter NADA de interface pronta: a lógica fica tão independente que chega a funcionar sem a interface. Então não precisamos esperar que o pessoal do desenvolvimento resolva aquele problema dos relatórios para que o pessoal do teste disseque nosso Caso de Uso. Maneiro, não?

Pontos negativos:

• Programação complexa

A programação torna-se mais complexa quando aplicamos o MVC. Chamadas consecutivas e abstração do código são extremamente importantes. Além disso, uma documentação de todo o projeto é imprescindível para que as camadas sejam mapeadas e seguidas da forma correta. Além disso, teremos o...

• Uso extensivo de padrões de projeto

O MVC simples já dita o uso do padrão Controller. Expandindo camadas de Comunicação e Armazenamento, ainda usaremos Proxies como o Remote Proxy e Database Brokers. Para desacoplar essas camadas, criaremos várias classes baseadas nos padrões Indireção (usado para desacoplar 2 classes que não deveriam ter visibilidade entre si) e Invenção Pura (padrão que adiciona classes que não estão diretamente ligadas ao problema em si, mas que facilitam a solução dele). No final, a relação entre as classes é bem mais burocrática

• Dependência do MVC na portabilidade

Para poder portar um código MVC de forma correta, o programa que irá recebê-lo precisa trabalhar nos moldes do MVC. Por exemplo, se estamos portando uma janela de cadastro de cliente já pronta para um programa parecido, ele tem que estar modularizado de forma a trabalhar com a classe Controladora para que a manutenção seja mínima. Isso causa uma certa dependência à estrutura.

• Queda de performance

As mensagens trocadas navegam entre camadas de forma burocrática e indireta, o que faz com que os programadores “performance acima de tudo” reclamem bastante. Por exemplo, uma chamada a uma função que seria direta numa programação estruturada torna-se uma cadeia de várias subchamadas a métodos que somente levam a chamada para a próxima camada nessa estrutura, como vocÊs viram no diagrama de seqüência lá em cima.

A performance perdida está longe de ser relevante, principalmente com os processadores de hoje em dia, mas mesmo assim continua sendo um ponto negativo da arquitetura.

“Ta, ta, eu entendi o MVC. Mas o quê que o Linkage tem à ver com isso???” O linkage do Flash é uma facilidade ao trabalhar com a interface, pois permite que uma classe use os atributos do MovieClip como se fossem atributos de si mesma. A grosso modo, parece muito uma herança de atributos e métodos públicos. O maior problema é que, se não tomarmos cuidado, acabamos destruindo toda a modularidade do MVC.

O linkage só deve ser usado para que as classes de interface controlem os MovieClips relacionados à elas. No nosso jogo, temos as classes TCarta e TCartaAvatar, ambas controlando uma carta em jogo. A diferença é que, seguindo o MVC, modularizamos uma carta em 2 camadas:

• TCarta

Controla a lógica da carta: os atributos, as contas, o dano que ela recebe, se ela está no Deck, na Mão, em Jogo ou no Cemitério e coisas do gênero.

• TCartaAvatar

Controla todos os efeitos visuais da carta. É ela que desenha a marcação do mouse sobre a carta, quem coloca a carta em qualquer posição, que inicia/pára o arrastar, que gera os efeitos de dano e desenha na tela todos os atributos buscados de TCarta.

Dessa forma, podemos trocar completamente a interface sem mexer nas classes de lógica. Trocar para Papervision 3D, a Plasticvision 4D, a Metalvision 5D ou até mesmo OpenGL ou ClosedLG, no nosso projeto, é muuuito mais simples: basta que criemos as mesmas classes de Interface, mas agora programadas com a nova interface. MOLEZA.

Essa portabilidade ainda pode ser da interface para a lógica: nossas cartas são arrastadas independente da lógica, elas brilham independente dlógica, elas se movem independente da lógica. Basta chamar os métodos da classe de Interface na hora certa, seja em Action Script 3.0 ou qualquer outra linguagem que o Flash suporte mais pra frente.

Caso uma única classe fosse responsável por isso tudo, durante uma troca de interface ou na hora de portar um trecho do código, a manutenção seria muito mais complicada: você deveria ficar movendo/apagando métodos das classes de lógica. Isso claro, pois estou pensando numa classe bem feita, com métodos bem estruturados. Muitas vezes, o que você encontra são linhas de interface no meio da lógica. Aposto que vários de vocês já viram um “se (this.morto) rode (“AnimacaoMorto”)”. Imaginem trocar o código para o futuro suporte OpenGL nesse caso...

Se vocês já pegaram o esquema do MVC e da expansão que fizemos, criando a camada de Armazenamento, já sacou que a carta também terá uma camada de armazenamento. Ela não está implementada ainda, mas seria mais ou menos assim:

• TCartaDados

Seria a classe responsável por materializar e desmaterializar a Carta. Pra quem não sabe, materializar é buscar os dados de um objeto no BD e criá-lo em memória e desmaterializar é jogar no BD, destruindo o objeto da memória. Essa classe também seria responsável por todos os outros métodos possíveis

Gente, de todos os artigos que fiz até agora, esse foi de longe o que eu mais gostei de escrever. Espero, por meio desse, ajudar a derrubar essa história de que o Action Script é uma linguagem de 2^a linha e que jogo em Flash é um amontoado de gambiarras. Espero também incentivar os leitores a escrever sobre qualidade de software em AS. Dá mais trabalho na hora de programar, mas esse trabalho é recompensado na hora de reutilizar o código em diversos outros projetos. Pensem nisso e até a próxima!

[EDIT] Não se esqueça de conferir o resto do artigo! Parte 1 e Parte 3, valeu?

Eu acredito que muita gente vai me chamar de maluco depois desse artigo, mas espero que todos entendam. Pra começar, vamos falar do MVC (ou Model-View-Controller), uma arquitetura de software baseado na idéia de interações emtre camadas de alta coesão (fazem exatamente aquilo que se propõem a fazer e nada mais que isso) e baixo acoplamento (são o mais independentes possível entre si).

“CALMAÊ!!!! QUE NEGÓCIO É ESSE DE ARQUITETURA??? O MVC NÃO É UM PADRÃO DE PROJETO???” Pois então, como eu disse, muita gente vai me chamar de maluco... Deixa eu explicar:Eu já vi vários sites, artigos e livros chamando o MVC de várias coisas. Já vi chamando de padrão de projeto, com o que eu não concordo. Ele não é um padrão de projeto pelo fato de organizar todo um sistema, não somente um bloco ou pequeno problema. Além disso, para implementar o MVC nós precisamos utilizar padrões, como o controlador (Controller).

Pensando nisso, algumas pessoas começaram a chamá-lo de meta-padrão, coisa que ele não é. Um meta-padrão definiria o comportamento dos padrões, não de toda a arquitetura.

O MVC é isso: ele define como as classes vão se comportar, ditando quem fica onde, faz o quê e, o mais importante, o por quê disso ser assim, bem como faz uma planta de uma casa. Por isso é que, em vários locais (como aqui no Nuss), vocês vão encontrar o MVC como uma arquitetura de software.

Isso é um ponto de vista, não chega a influenciar diretamente no uso do MVC. Mas é importante explicar para que ninguém saia com “cara de LG”. Beleza? Então continuemos com o artigo.

Voltando às camadas, é como se você transformasse o software no corpo humano: separasse os ossos e delegasse a eles a sustentação do corpo, o sangue ficaria com o transporte de substâncias pelo organismo e o sistema neurológico se responsabilizasse pela propagação das sensações e ordens do cérebro. É claro que as funções não são bem essas, mas é assim que as coisas funcionam.

O MVC em nosso jogo fica assim:

Com esse diagrama eu posso falar da maior característica do MVC: Toda e qualquer camada só se comunica com as camadas imediatamente abaixo de si. Lembrando-se que, para evitar dúvidas, quanto mais próxima do usuário, mais “alta” ou “alto nível” está a camada. Nota-se que nenhuma classe da Lógica realiza chamadas à classe Controladora da mesma forma que a classe controladora não realiza chamadas à Interface. Além disso, a Interface não chama diretamente método algum da Lógica: isso é feito através da classe Controladora, como mostra o Diagrama de Seqüência a seguir:

No MVC, cada camada tem uma função específica:

• Model (Modelo / Lógica)

Essa é a camada de negócios, onde está toda a lógica do teu sistema. No Jogo, por exemplo, é onde estão as classes TCarta, TPersonagem, TLadrilho e todas as outras relacionadas ao funcionamento do núcleo do Jogo (ou engine, se preferir).

• View (Visão / Interface)

Na camada de visão você não encontra NADA além das classes de interface com o usuário. TCartaAvatar, TPersonagemAvatar e TLadrilhoAvatar são exemplos de classes que, no Jogo, ficam na Interface. Outras classes que estão aqui são a TIdioma (que controla todos os textos do programa) e a TJukeBox (recém implementada, que controla todos os sons do jogo)

• Controller (Controladora)

A controladora é uma camada intermediaria entre a Lógica e a Interface, que faz somente a propagação das mensagens da interface para a lógica, visto que a lógica não pode se comunicar com a interface.

A continuação do artigo, com os prós e contras da arquitetura, além do que o Linkage do flash tem a ver com isso vai ficar para o próximo. Então gente, até lá!

[EDIT] Seguem os links para as Partes 2 e 3 do artigo.