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.

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.

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;

Vamos tomar como exemplo um ComboBox:

Você adiciona o componente no Stage e insere os dados no mesmo (label, data, etc), certo? O componente é responsável por exibí-los. Assim, podemos dizer que você usa um ComboBox e tem acesso às propriedades necessárias para personalizá-lo ao seu modo (Talvez o combo do flash não seja o melhor exemplo de personalização, mas essa é outra história). Já pensou se você precisasse programar um código para que depois de um numero x de elementos fosse inserida uma rolagem no combo? Felizmente, neste conceito (e no do Flash, graças a Deus!), você não precisa. O combo é responsável pelos seus estados (lembre dessa palavra! Vamos lá, repita comigo: estado, estado, estado…), e é ele quem deve cuidar da sua rolagem independente do número de itens que possua.

Vamos supor que o nosso combo possua uma variável estática (que consequentemente tem o mesmo valor para todos os combos – ou em se tratando de OOP propriamente dita, para todas as instâncias do objeto) chamada MIN_ELEMENTS, que é responsável por armazenar o número mínimo de elementos visíveis, cuja declaração seria a seguinte:

public static var MIM_ELEMENTS:Number = 1;

Então, por descuido ou qualquer outro motivo alguém resolve escrever o código:

ComboBox.MIM_ELEMENTS = -10;

A variável é publica e pode ser acessada de qualquer lugar. Mas me diga, é possível renderizar -10 itens? Você acha possível que a alteração de um atributo como este poderia afetar o funcionamento do combo? É provável que sim. Não precisamos ter acesso a atributos deste gênero para utilizar o nosso objeto combo, mas é um dado importante dentro do mesmo. Assim a declaração correta seria:

private static var MIM_ELEMENTS:Number = 1;

Agora esse atributo só é visível dentro da classe e só pode ser alterado internamente.

Vamos a outro exemplo. Temos uma classe Pessoa e um de seus atributos é sexo e seu conteúdo pode ser feminino ou masculino.

class Pessoa
{
    public var sexo:String;
    // continua o codigo
    //  ...
}
 
var p:Pessoa = new Pessoa();
p.sexo = "Maria";

A variável sexo é pública e do tipo String portanto poderia aceitar tranquilamente a String“Maria”, entretanto, isso pode – e provavelmente irá – comprometer o funcionamento do nosso objeto, tendo em vista que o sexo “Maria” definitivamente não existe. Assim, utilizamos recursos de encapsulamento de OOP para proteger o nosso objeto. Os getters e os setters.

class Pessoa
{
    private var _sexo: String;
 
    public function get sexo():String
    {
        return _sexo;
    }
 
    public function ser sexo(value:String)
    {
        value = value.toLowerCase();
        if (value == "feminino" or value="masculino")
            _sexo = value;
 
        // caso nao fosse atribuido poderia ser disparado um evento,
        // ser gerada uma excessao,
        // exibir uma mensagem de erro e por ai vai.
    }
}

No exemplo acima, garantimos que será inserido apenas um dado válido. E o getter? Bom, se você restringe o acesso a um dado e ele precise ser visto fora do objeto, é necessário disponibilizá-lo (se e somente se ele realmente precisa ser visto de fora). Mas não confunda! O getter pode conter outras coisas além do retorno do atributo.

Geralmente quando se começa a aprender OOP (seja para criar o hábito, começar a identificar necessidades, ou qualquer outra coisa que se possa querer com isso) se indica utilizar atributos privados para tudo (ou quase) e a criação de getters/setters de todos eles. Isso porque quando se vem de uma linguagem procedural se pode fazer tudo com todos os “atributos”, não existe encapsulamento e literalmente “todo mundo é de todo mundo”. Então tenta-se a criar (ou modificar) uma cultura. Se isso é certo ou não… é um jeito (e a maioria dos programadores em algum momento passam por essa fase, depois passamos a fase de nos livrar do hábito do excesso).

A identificação das necessidade da utilização desses metodozinhos vem com a experiência. É preciso saber identificar quando o usuário pode inserir um dado diretamente, quando ele pode ver um dado, quando ele pode inserir algum dado mas com restrições, quando você precisa saber se um dado é inserido, etc… Uma forma de saber isso antes de colocar a mão na massa é a modelagem. O código abaixo por exemplo é apenas uma maneira burocrática de “gerar uma variável pública”.

private var _sexo: String;
 
public function get sexo():String
{
    return _sexo;
}
 
public function set sexo(sexo:String)
{
    _sexo = sexo;
}

Então… Vamos modelar, modelar e modelar?