abstrair

Conjugar
do Lat. abstrahere

v. tr.,
fazer abstracção;
separar mentalmente (as qualidades ou propriedades dos seres);
afastar, desprezar;

v. int.,
considerar isoladamente;
simplificar;

v. refl.,
distrair-se;
alhear-se;
concentrar-se, absorver-se.

E o substantivo abstração:

abstracção

do Lat.  abstractione

s. f.,
acção de abstrair;
separação mental de uma das partes de um todo;
estado da pessoa absorta em profunda meditação, contemplação, êxtase, enlevo;
distracção;
hipótese.

Tudo bem, mas o que é abstração quando se fala de orientação a objetos? É exatamente o que o dicionário diz. Abstração não é algo de OOP, mas é sim uma das bases deste paradigma. E pra quem não sabe o que significa paradigma:

paradigma | s. m.

paradigma
s. m.
Gram. Modelo (de conjugação ou de declinação).

Sempre fui da idéia de não repetir uma palavra ou um conceito só porque é usado dessa forma e aceitar isso… Me agrada saber o que eu estou falando. Dizem que OOP é um paradigma de programação (análise e/ou projeto) que se baseia em unidades chamadas objetos. Então vamos abstrair. Ignoremos o português engomadinho. OOP é um modelo ou um jeito de se programar onde a gente trata os pedacinhos do sistema como coisas do mundo real.

Então aproveitando o mundo real, posso dizer que nós somos instâncias da classe Pessoa. E pessoas tem características. Como cor de olhos e cabelos. Mas do que interessa num sistema de cadastro de newsletter a cor dos cabelos do usuário? Absolutamente nada! Então esqueça isso. Se a orientação a objetos diz que devemos programar as coisas como são no mundo real, a abstração, que é uma de suas bases, diz: “mas não exagere, o mundo real é um sistema muito mais complexo que o seu cadastro de newsletter“. Devemos criar objetos. Eles devem ser “vivos”, mas precisam ser coerentes com seu universo.

Indo além da abstração, se nessa vida posso lhe dar um conselho sobre OOP é: cuidado com objetos complexos. Normalmente eles são formados por outros objetos. E essa é a parte difícil pra quem sai de uma linguagem procedural para OOP. É ai que as vezes algumas pessoas pecam. Elas misturam tanto que uma Pessoa (do mudo real), é apenas uma pessoa e não um objeto complexo formado por  objetos menores. É como se o cérebro fizesse tudo ao invés de mandar as outras partes fazerem o trabalho delas. O objetivo não é entrar em uma aula de anatomia, então do que estou falando?

Lembra do cadastro de newsletter? Vamos supor que nesse caso o usuário precisa interagir com um formulário. Neste formulário temos dois campos (nome e email) e um botão (enviar), precisaremos ter uma outra telinha, que irá mostrar a mensagem de status do envio do cadastro e precisamos dar ao usuário a oportunidade de voltar para a tela anterior. Então, o cadastro de newsletter é formado por dois objetos: formulário e tela de resposta. O formulário por sua vez é formado por 3 objetos: dois campos (instâncias de uma mesma classe) e um botão. Enquanto a tela de resposta é formada por 2 objetos: um campo de mensagem e um botão de voltar. Com isso, posso concluir que, um cadastro de newsletter é um objeto complexo, formado por 2 objetos complexos, formado por n objetos… É assim que se programa em OOP, mas por que dividr tanto? Reuso. Esta é a resposta chave. Mas eu acrescento outras coisas que vem de brinde: organização, flexibilidade e independência entre as partes.

Vamos tentar entender mais sobre isso… Se eu tiver um objeto do tipo FormResponse (me desculpem a falta de documentação, mas não queria deixar o bloco muito extenso):

package
{
	import flash.display.MovieClip;
	import flash.events.MouseEvent;
	import flash.text.TextField;
 
	public class FormResponse extends MovieClip
	{
		public function FormResponse()
		{
			this.visible = false;
			this.backButton.addEventListener(MouseEvent.CLICK, this.handleBackButtonClick);
		}
 
		public function show(message:String):void
		{
			this.messageText.text = message;
			this.visible = true;
		}
 
		public function hide():void
		{
			this.visible = false;
		}
 
		private function handleBackButtonClick(event:MouseEvent):void
		{
			this.dispatchEvent(new Event("backButtonClick", true));
		}
	}
}

Você concorda que seria muito mais simples lá na minha classe principal eu usar um objeto desses, através dos métodos show e hide, ao invés de fazer todas ou parte destas instruções repetidamente sempre que precisasse mostrar uma mensagem?

Se eu não escrevesse esta classe, la na minha instância principal eu teria (supondo que todos estes elementos estão adicionados no palco):

this.formResponse.visible = true;
this.formResponse.messageText.text = "mensagem";
 
this.formResponse.backButton.addEventListener(MouseEvent.CLICK, handleBackButtonClick);
 
function handleBackButtonClick(event:MouseEvent):void
{
	// seu codigo aqui
}

Mas eu posso ter apenas isso:

this.formResponse.show("mensagem");

E o melhor é que se eu quiser fazer uma animação para a entrada/saída, por exemplo, eu preciso apenas alterar a classe FormResponse, enquanto na versão bagunçada ali em cima eu precisaria mudar o código em todos os lugares onde ele aparece.

Simples, não?

Normalmente as pessoas comparam muito interfaces com classes abstratas, mas são coisas completamente distintas e com objetivos bem diferentes, por isso, ao contrário da maioria, não vou abordar as duas coisas juntas.

Características das classes abstratas:

• Pode-se dizer que é uma classe incompleta.
• Não pode ser instanciada (perfeitamente justificada pelo item acima).
• Pode ou não ter métodos abstratos (tem quem diga que deve ter pelo menos um, caso contrário poderia ser uma classe concreta, mas isso é uma questão de ponto de vista e de quão a risca se deve seguir a teoria).
• Uma classe que tenha um método abstrato deve ser obrigatoriamente declarada como abastrata, ou seja, não existe método abstrato fora de uma classe abstrata.
• Pode ou não ter métodos concretos.
• Quando uma classe concreta herdar uma classe abstrata todos os métodos abstratos devem ser implementados.
• Uma classe abstrata pode herdar outra classe abstratas e os métodos abstratos só serão obrigatórios na primeira classe concreta da hierarquia.

Assim como com classes concretas e interfaces podemos utiizar delas também para realizar operações polimórficas.

As classes abstratas são bastante usadas como template, se quiser entender um pouquinho mais sobre isso, dá uma olhadinha aqui: Template Method.

Onde isso faz falta?

Suponha que você queira manter 2 imagens iguais aparecendo na tela para simular um efeito de espelho ou que você precise mostrar um thumb e uma imagem grande e esta imagem é carregada dinâmicamente. Você não pode simplesmente dar addChild uma segunda vez, pois o seu objeto vai se mover. Sim, ele vai sumir do lugar antigo e aparecer no novo lugar, mas por quê? Não era para ser uma referência na memória? Sim, continua sendo, mas… Todo DisplayObject possui uma propriedade parent que faz referência ao DisplayObjectContainer onde ele foi adicionado. Sempre que o método addChild é chamado o valor da propriedade parent é alterado e consequentemente o DisplayObject deixa de estar no lugar anterior, porque afinal de contas ele só tem um pai.

Para Bitmap felizmente existe um jeitinho, mas para outros DisplayObject, não. Mas o que um Bitmap tem de tão especial? Um objeto Bitmap tem em sua composição um objeto BitmapData, e este por sua vez tem o método clone implementado. É na propriedade bitmapData que estão armazenadas todas as características da imagem. Segue um exemplo com um Bitmap gerado pelo código, mais especificamente um quadrado vermelho, veja como é simples:

// criando um bitmap (quadrado)
var bitmap:Bitmap = new Bitmap(new BitmapData(100, 100, false, 0xBB0000));
 
// adicionando bitmap no palco
this.addChild(bitmap);
 
// criando um novo bitmap com o clone do bitmap data
var bitmapClone:Bitmap = new Bitmap(bitmap.bitmapData.clone());
 
// modificando o posicionamento p/ enxergarmos os 2 elementos
bitmapClone.x = 100;
bitmapClone.y = 100;
 
// adicionando o clone no palco
this.addChild(bitmapClone);

Se uma imagem é carregada dinamicamente o processo é exatamente o mesmo, já que todo objeto Bitmap possui em sua composição um BitmapData sendo ele carregado externamente ou não. Então aproveitamos o que a imagem já tem. Segue um exemplo:

// declara e instancia um objeto loader
var loader:Loader = new Loader();
 
// adiciona listener para o carregmento da imagem
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, handleLoadComplete);
 
// define uma url para carregamento
var urlRequest:URLRequest = new URLRequest("http://www.nyan.com.br/ico/it.png");
 
// inicia o processo de carregamento
loader.load(urlRequest);
 
// handle para o evento de complete
function handleLoadComplete(event:Event):void 
{
	// cria referencia para a imagem carregada
	var image:Bitmap = loader.content as Bitmap;	
 
	// adiciona a imagem no palco
 	this.addChild(image);
 
	// cria um novo bitmap e adiciona um clone 
	// do BitmapData contido no Bitmap carregado
	var imageCopy:Bitmap = new Bitmap(image.bitmapData.clone());
 
	// adicionando copia no palco
	this.addChild(imageCopy);
	// mudando posicionamento para enxergarmos
	imageCopy.x = 100;
 
}

Tem mais uma coisa interessante nisso: se você declarar um novo Bitmap, atribuindo a ele um BitmapData existente mas sem chamar o método clone, também vai funcionar. A diferença é que se você fizer qualquer alteração no bitmapData através de qualquer um dos Bitmaps, ambos serão alterados, o que não acontece quando invocamos o método clone, pois ele sempre retorna uma nova instância. Este é um bom exemplo pra entender a diferença entre instâncias e referências.

Eu sempre achei o Twitter ridículo (embora eu tenha um), mas trabalhar com internet e ter que se manter atualizado (ou simplesmente ser curioso) te força a conhecer certas coisas ao menos pra saber do que você está falando. Pois é, foi assim que criei a minha conta no Twitter. Hoje não acho que ele seja ridículo ou inútil, mas a maneira como é utilizado pela maioria das pessoas não me parece muito inteligente. Nunca gostei de twittar, mas de ler os twits alheios (a febre é tanta que virou até verbo). Depois de um tempo comecei a parceber que este novo hábito tomava uma parte do meu dia e isto de certa forma começou a me preocupar, afinal de contas que informação útil tem em “hoje não consegui lavar minhas calcinhas”, “meu time perdeu de novo”, “alguém viu minha xícara por aí?”, “não quero mais trabalhar”, etc. Me parece que o mundo humano, real e tátil está caindo em desuso. As pessoas não conversam mais e as redes sociais estão virando uma forma de escape ou uma forma de não se sentir só.

Na época que o orkut estava em alta, eu era uma anti-orkut principalmente porque nunca fui favorável à modismos. Mas me inscrevi lá também. Uma porque não tinha idéia do que existia lá dentro e outra porque boiava completamente quando meus amigos entravam no assunto. Enquanto era uma rede social tudo bem, mas virou uma rede de frescuras para continuar mantendo as pessoas. Juro que até tentei ter um daqueles bonequinhos que indicam o seu humor e interage com seus amigos. Hoje minha conta é um pouco abandonada: me conecto vez ou outra pra ver se tenho algum recado, respondo e paro por aí.

Enquanto o orkut foi (ou é, não sei mais) modinha no Brasil, o facebook é a rede social do momento na Itália. E meu interesse nessa rede foi exatamente este. Entrar em contato com parte dessas pessoas para ter mais contato com a língua e com a cultura que sempre me dispertaram tanta curiosidade. É, rendeu. Mas se você faz parte da minha rede de amigos, não me convide para usar aqueles diabos de aplicações. Esse tipo de coisa consome muito tempo.

E por falar nisso, muitas aplicações consideradas 2.0 (não vou entrar nesse mérito) enxergaram a rede social como um nicho para se espalharem ainda mais. É como o netvibes onde você pode ter sua página pública. Ou o delicious onde você tem seu networking. Sinceramente, os meus viraram um aglomerado de informações. Meu delicious tem mais links do que eu consigo ver. Tem coisas que estão lá dentro. Eu sei que estão… mas não tenho a menor idéia de onde. Ter a informação é bom, mas é mais importante saber o que guardar.

No fim das contas, todo mundo vive reclamando que não tem tempo para fazer certas coisas. Será que não temos realmente tempo ou estamos dedicando nosso tempo livre para fazer coisas sem importância? Sei lá. Algumas vezes tento me imaginar desconectada de toda e qualquer rede social na internet… mas acho que isso é meio impossível. É como se desconctar do mundo. Então me pergunto: qual é o limite entre viver no real ou no virtual, considerando que aparentemente tudo isso virou uma coisa só?

…

O mais bizarro de tudo é que esse post vai parar automaticamente no meu twitter e no meu facebook e talvez você tenha vindo até aqui através deles.

Não é necessário comprimir o arquivo (gerar um zip, um rar ou qualquer outra coisa) ou forçar pelo php, .net, etc. Você pode usar a  classe FileReference. Todo mundo lembra dessa classe na hora de fazer upload, mas a maioria esquece o método download que abre a caixa de diálogo no navegador para salvar o arquivo. 

O código é muito simples:

// definindo url do arquivo
var fileURL:URLRequest = new URLRequest("http://www.nyan.com.br/ico/feed.png");
 
// instancionado objeto file reference
var fileReference:FileReference = new FileReference();
 
fileReference.download(fileURL);

Só não esqueça de uma coisa: O Flash Player 10 sofreu várias atualizações de segurança e uma delas está diretamente relacionada à classe FileReference. Não é possivel chamar os métodos download ou browser se não for através de uma interação do usuário (pressionando uma tecla ou clicando com o mouse, por exemplo).

Se você reparar bem, quando falamos de aproveitamento de código em OOP, esse padrão é a base de quase tudo - ou a base de quase tudo se parece muito com ele. O problema dele em relação ao ActionScript é que ele é baseado em classes e métodos abstratos e como a linguagem ainda não disponibiliza este recurso, podemos apenas tapar um olho e simular o padrão.

Nota: Eu particularmente gosto de usar o prefixo Base em todas as classes que crio em AS e que em teoria deveriam ser classes abstratas. Ao menos assim existe uma forma simples e rápida de identificá-las dentro da estrutura de um projeto ou framework.

Segue um exemplo extremamente simples (e sem funcionalidade) só para entendermos alguns conceitos. 

Classe “abstrata”:

package
{
	public class BaseTest extends MovieClip
	{
		public function BaseTest()
		{
		}
 
		// definindo um método que não pode ser sobrescrito
		public final function finalMethod():void
		{
			// chamada a método opcional (gancho)
                        this.hookMethod();
 
                        // implementação padrão
			this.x = 200;
 
			// chamada ao método que será sobrescrito
			this.customMethod();
		}
 
		// método que deveria ser abstrato
		protected function customMethod():void
		{
			// implementação na classe concreta
		}
 
		// método gancho que pode ou não ser sobrescrito
		protected override function hookMethod():void
		{
		}
        }
}

Classe concreta:

package
{
	public class CustomTest extends BaseTest
	{
		public function CustomTest()
		{
		}
 
		// método que deveria ser abstrato
		protected override function customMethod():void
		{
			// implementação personalizada obrigatória
			this.y = 45;
                }
        }
}

Neste padrão as chamadas normalmente ocorrem mem modo inverso daqueles que normalmente aplicamos. Ao invés de fazer a chamada ao código comum (ou código reutilizado) na classe filha (CustomTest), fazemos as chamadas pela classe pai (BaseTest). Assim, é possivel garantir o fluxo de execução das tarefas pelo objeto.

Podemos observar também que na classe “abstrata” os métodos públicos (que são implementados) são declarados com a palavra reservada final, isto significa (garante) que ele não poderá ser sobrescrito. Os métodos personalizáveis, ao contrário, são declarados como protected permitindo que sejam sobrescritos através de herança.

As principais chamadas que a classe “abstrata” faz são as seguintes:

Métodos concretos

Da classe abstrata - implementações úteis a todas as classes filhas -, da classe concreta ou de outras classes.

Métodos abstratos

Devem obrigatoriamente ser sobrescritos. Isto é um problema pois não conseguimos garantir a sobrescrita de um método utilizando ActionScript a não ser que seja por interfaces.

Métodos ganchos

Podem ou não ser sobrescritos e são uma implementação opcional. É uma maneira de utilizar herança de forma controlada. Estes métodos não possuem implementação na classe abstrata.

É interessante que ao usar essa idéia em ActionScript seja definido um padrão para os nomes dos métodos, que facilite a identificação do métodos que são obrigatórios (teoricamente abstratos) e dos que são opcionais, ainda que não se tenha a garantia de um método abastrato.

Se não existe, onde fica toda essa galera que programa para flash? Sinceramente, eu não pensei muito no todo, mas na pequena parcela que pode ser chamada de programador. Ou você é programador ou você não é e isso independe da linguagem que você decidiu se especializar. Um programador conhece e domina lógica - e nos dias de hoje OOP é fundamental - e depois só precisa aplicar isso na linguagem dos seus sonhos (Tá, não é só isso, mas não quero ficar fazendo listas de x ou y).

Mas, segundo o dicionário essa é a definição de programador:

Inform.,
aquele que cria programas de computador.

Aposto que quem escreveu essa definição não é programador e nunca teve que alterar um código que mais parecia uma macarronada ou as paredes de um quarto pintadas por uma criança de 5 anos… E sendo realista, não existe programador flash principalmente porque o Flash não é uma linguagem de programação e sim um aplicativo. Só que isso é um erro de nomeclatura ( que cá pra nós devia ser corrigido ) e não é o foco desse post, então eu vou dividir o universo do “programador flash” em 2 partes principais: os programadores e os não-programadores.

O cara que faz funcionar, entende como funciona o programa, fuçou horrores na vida, mas parou por aí é um não-programador. Ele conhece sintaxe, mas normalmente não sabe exatamente o que está fazendo. Ele só sabe que vai funcionar porque está assim no exemplo que ele achou na internet ou porque ele já fez 500 vezes desse jeito. Infelizmente, é o que mais tem no mercado e digo infelizmente não pelo mercado apenas, mas pelo futuro profissional dessas pessoas. Boa parte de quem programa para Flash tem um início sem embasamento teórico nenhum: são designers, publicitários, curiosos… Mas essas pessoas nunca serão programadores ActionScript? Depende de cada um. Conheço ótimos programadores que começaram assim, na curiosidade. Um programador tem que ser capaz de entender a lógica e também de produzir coisas lógicas ( e que de preferência não tenham lógica só na cabeça dele, que é o que acontece muito nesses casos ). 

O Programador ActionScript sabe o que está fazendo, mas ele pode ter muita ou pouca experiência. Ele possui n níveis de especilização e isso varia conforme sua experiência com a linguagem, mas não considere isso como anos trabalhados. 

Mas onde está o bom ou o mal programador? Bem, pra mim, em termos de código ele nã existe. O que define se alguém é um mau programador ( ou mau profissional ) são suas questões éticas e seus princípios. Cada um deve conhecer os seus limites, fazer o que está de acordo com suas habilidades e ter noção de quanto pode arriscar as coisas em um projeto deixando isso muito claro para todos os envolvidos. 

Alguém que realmente é bom ( e bom em qualquer coisa ) está sempre procurando acompanhar a evolução do nicho no qual está inserido. Sempre dando uma olhadinha aqui e outra ali tentando melhorar sua lógica, seu código e sua experiência. Aliás, um programador mais experiente normalmente agrega velocidade aos projetos, mas não quer dizer que um menos experiente necessáriamente vá produzir um código pior, ele só vai levar mais tempo. 

Em fim…

E pra não dizer que é só um surto por camisetas “nerd“, tem também um guia de referência rápida feito pelo próprio Jason McDonald, com um resuminho de cada Design Patterns do GoF. Para ver o PDF clique na imagem abaixo. 

O post é antigo, mas eu adorei. E você?

// declarando variável
var content:MovieClip;

Quando um objeto for criado - uma nova instância pode ser gerada através do operador new -, obtém-se uma referência, que é armazenada na variável.

// cria instância de MovieClip
content = new MovieClip();

Neste exemplo, content é uma variável que armazena um endereço de memória, no qual existe um objeto do tipo MovieClip. A variável content mantém apenas a referência para o objeto e não o objeto em si. Assim, numa atribuição como a mostrada abaixo, não será criado outro objeto MovieClip, mas uma nova referência para ele.

// atribuindo referencia de content a content2
var content2:MovieClip = content;

Um dia o Tiago Schenkel, programador ActionScript da AG2 Pelotas, me mandou um link de convenções de código e melhores práticas para Flex. Uma documentção da própria Adobe - veja aqui -  e disse:

Dani, essa tu vai gostar!

É, realmente gostei. Sempre vi uma penca de padrões quando vivia no universo sistemas, mas Flash na AG2 está no universo interfaces. Fiquei com aquele documento em mente e comecei a me lembrar o quanto a Lú falava que não conseguia entender a organização do código do Fernando e vice-versa. Até que um dia o Mozart me procurou pra falar que precisávamos  adotar alguma convenção de código. E de fato ele tinha razão. Eu tinha/tenho meus vícios de código, assim como cada um. Agora vivemos num universo de constante adaptação, mas onde todos devem seguir juntos. 

Essa é só mais uma história do mundo real onde a ausência de padronização pode gerar classes confusas e atrasar o trabalho como um todo. Este post é só um pensamento sobre isso. As vezes dá pra se questionar se a tudo não fica burocrático demais. Acho que não! A diferença é que toda uma equipe mantém os mesmos  ”vícios” e assim um pode continuar o trabalho do outro sem ficar varrendo uma classe para saber onde foram colocados os getters. 

Como é o tipo de documento a ser mantido e atualizado por um grupo de pessoas tende a ficar cada vez melhor. Os hábitos vão sendo adotados gradualmente e com o tempo todos escrevem classes muito mas legíveis. Consequentemente, sistemas muito mais claros.