Nesta aula a dificuldade foi desenhar o abacaxi, que sem dúvida nenhuma é uma abacaxi daqueles .

Desenho 1. 06 julho, 2010.

Desenho 2. 06 julho, 2010.

Desenho 3. 06 julho, 2010.

Pausa para estudo do Abacaxi.

Desenho 4. 06 julho, 2010.

Desenho 5. 06 julho, 2010. 15 minutos.

Comecei minhas aulas de desenho no dia 11 de junho e vou postar gradualmente todos os desenhos feitos desde então. Não espere nenhuma obra de arte, na maioria das vezes são estudos para a prova específica da UFRGS e o tempo para cada desenho é somente de 15 minutos.

Então, ai vão os desenhos da minha primeira aula. O material usado é folha A2 e lápis 6B.

Primeiro desenho.

Tempo: 30 minutos.

Os riscos mais fortes são da minha professora, Kátia Costa, do Atelier Plano B. Ela me deixou desenhar para ver o que eu sabia e então começou a me instruir. Aquela linha claro-escuro uniforme foi algo que tentei aprender sem sucesso. Depois de mais de um mês desenhando frequentemente, passo a concordar que desenho é prática, assim como escrever. O detalhe é que cada um tem “sua letra” (traço, neste caso) e definitivamente daquele jeito não consigo fazer. Não naturalmente.

Primeiro desenho. 30 minutos.

Segundo desenho.

Tempo: 30 minutos.

Depois de algumas preciosas dicas, ainda com um traço de quem está aprendendo a escrever, dá pra ver uma melhora considerável na questão de luz e sombra. O pote frontal ficou redondo demais, e o pote em cima do banco, ganhou muitos rabiscos na tentativa de arrumá-lo…

Segundo desenho. 30 minutos.

Terceiro desenho.

Tempo: 20 minutos.

O tempo foi reduzido em 10 minutos. Não foi possível fazer todas as hachuras, principalmente nas folhas e tecido. Alguns objetos ficaram disformes.

Terceiro desenho. 20 minutos.

Estudo folhagem.

Confesso que até hoje tenho dificuldades com essa planta. Fiz um estudo já na primeira aula.

Estudo folhagem.

É muito bom ter amigos talentosos (dá um orgulho!). A copa que interessa é mais nova idéia concretizada do @munuzus. Ainda não li todo o livro (que recém saiu da gráfica e já tive o privilégio de ver aqui na Boca), mas dei uma passada por algumas seleções. E como não sorrir com “…e todo mundo sabe como é difícil torcer contra um time de uniformes bonitos”? A genialidade de quem amou o que escreveu simplesmente pode fazer alguém como eu (que nem entende tanto assim de futebol), se sentir perito ou, quem sabe, fazer de conta que é.

O lançamento é na quarta, dia 26/5, no Caminito, as 18h30min.

Pra saber um pouquinho mais sobre o livro, clica aí.
http://www.dublinense.com.br/proximos-lancamentos/a-copa-que-interessa/

http://www.seuczar.org/menezes/?p=1221

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.