Abstração?

Vamos seguindo com o assunto OOP. Hoje vou falar um pouquinho de abstração.
Para não deixar dúvidas sobre o significado da palavra de forma geral, segue a definição do dicionário para o verbo abstrair:

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?