Rodrigo Allemand

Recentemente saiu na Java Magazine uma matéria sobre Proxys do Guerra, muito boa por sinal.

Mas como o objetivo da revista é apenas passar a informação e não aprofundar num exemplo mais real, resolvi escrever sobre Proxys, já que por várias vezes há a necessidade de criarmos esse artifício nos sistemas da vida.

Primeiramente, a definição:

Provide a surrogate or placeholder for another object to control access to it.

Resumidamente, ele cria uma barreira e/ou um ponto de acesso para outros objetos. Seria como um Proxy (dããã) de rede. Pra vc sair ou entrar numa rede, vc precisa passar por um proxy. Lembra disso, né?

Basicamente, os proxys são divididos em Estáticos e Dinâmicos. Estáticos quando a implementação está fisicamente presente, seja uma classe ou uma interface ou um serviço. E dinâmico, quando a implementação não existe fisicamente.

Eu encaro tambem um outro tipo de proxy, que seria o de acesso controlado. Ele é estritamente estático, mas atua completamente diferente de outros estáticos que você verá.

Proxy para acesso controlado a um objeto

Lembra do meu Post sobre FluentInterfaces? Lembra da minha lista de notificações? Então, ela era um Proxy de acesso!

Vamos aos detalhes!

public class NotificationList
		extends ArrayList<NotificationMessage> {
	private static ThreadLocal<NotificationList> threadList
		= new ThreadLocal<NotificationList>();

	//Construtor é privado para o controle da ThreadLocal
	private NotificationList() {}

	//Método que retorna/cria a lista
	public static NotificationList getList(){
		NotificationList list = threadList.get();
		if(list == null){
			list = new NotificationList();
			threadList.set(list);
		}
		return list;
	}

	//Método que limpa as mensagens
	public static void clearMessages(){
		NotificationList list = getList();
		list.clear();
	}
}

O pulo do gato está em ter os métodos estáticos e garantir que o acesso, tanto à ThreadLocal que guarda a lista quanto a criação da lista, seja feito apenas pelo proxy.

Proxy Estático

O segundo exemplo é um proxy estático. Vou deixar esse exemplo para a matéria da revista. Eu não concordo muito com esse tipo de proxy para aplicações reais e bem feitas. Não vejo sentido em ter uma interface, uma implementação de proxy e um objeto. Achei o exemplo um pouco sem sentido, mas, vocês devem comprar a revista pra ver se realmente eu estou certo.

Só pra adiantar, o exemplo é um log sobre uma classe de serviço. Então criou-se uma interface com os métodos do serviço, a implementação desse serviço e um proxy que implementa a interface e tem a implementação do serviço internamente, fazendo com o que a cada chamada de um método, seja feita um log antes.

Proxy Dinâmico

O terceiro exemplo seria um proxy dinâmico. Esse é um exemplo legal de se montar.

No próximo post eu vou detalhar a contrução de uma tentativa de criação de um findBy do ActiveRecord como o do Rails.

Porque este exemplo? Porque o Rails se utiliza de uma coisa parecida, que é o missing_method.

A ideia é fazer assim: se eu quizer buscar por nome e sobrenome, eu chamaria o método findByNomeSobrenome(x, x); se fosse por nome, sobrenome e idade, chamariamos o método findByNomeSobreNomeIdade(x, x, x). Sinmples, né? Só tem um detalhe: Vamos implementar apenas um método findBy(x[]) e fazer com que ele absorva todas essas chamadas da interface!

Até!

Comente e Recomende!

A primeira vez que eu (quase todos) ouvi falar em testes automatizados, pensei comigo:

Capitão, isso vai dar merda!

Como qualquer pessoa eu cometi/pensei algumas das 5 maiores desculpas para não desenvolver testes!

• O prazo vai aumentar, com certeza!
• O sistema é pequeno. Seria um canhão numa formiga!
• Sou bom e o sistema é simples. Pra que testes?
• E as funcionalidades complexas, que são “intestaveis”!?
• E a galera de teste? O que fará?

Fala sério?! Você tambem pensou nisso tudo a primeira vez (que pode até ser agora)!

Como falei, isso foi a muito tempo atrás, posso falar que a uns 4 anos.
Com o tempo eu fui tentando, testando e hoje, quase tudo o que faço tem algum tipo de teste!

Teste é um dos pilares de um desenvolvedor ágil! Há xiitas quem diga que, sem testes, o seu código não existe!

Mas como testar?

Bem, mais uma vez, pretendo criar uma série de posts pra tentar passar a técnica e a arte de criar testes.

Inicialmente, vamos entender o que é testar!

Testar é simplesmente verificar se o seu código está de acordo com uma determinada regra.

E o que é teste automatizado?

É fazer com que o seu teste seja executado automaticamente e te dê um relatório final, sem necessidade de intervenção sua para isso, ou que esta esteja ligado a alguma ação que você efetue com frequência.

Bem, a tendência é que você teste a cada alteração no código, correto? Nada melhor do que colocar os testes ligados ao momento do deploy, ou seja, antes de gerar o deploy, mande executar os testes. Com isso vc vai garantir que os seus códigos estão sempre testados, e irá executar os testes diversas vezes ao dia…

Basicamente existemdois tipos de metodologias para testes, o TDD (Test Driven Development ou Desenvolvimento Orientado a Testes) e BDD (Behavior Driven Development ou Desenvolvimento Orientado a Comportamento). Vocês vão perceber que ambos se assemelham, afinal, o propósito básico é testar! Mas inicialmente vamos focar em TDD.

O script básico de um cíclo de testes é o seguinte:

• Desenhe o que você quer que seu código faç
• Escreva o teste
• Rode o teste, provocando a falha
• Refatore o código para passar no teste
• Reinicie o cíclo

Essa adoção foi chamado por James Shore de Red-Green-Refactor. Explicando melhor:

• Red: Seu código não passou no teste. Refatore seu código!
• Green: Seu código passou no teste. Refatore o teste!

Claro que isso tem que ser bastante controlado! Você não pode escrever muita coisa em cada cíclo. Você deve caminhar devagar, em poucas linhas de código, em poucos cenários de teste. Senão você vai entrar em um looping infinito e jamais sairá do outro lado! A unica parte que vc deve perder um tempo consideravel é a parte onde vc desenha o que o seu código deve fazer, ao final de tudo. Mas tambem nada muito exosbitante não senão o conceito de ágil vai pro buraco!

Outra coisa: não se preocupe com design e padrões nesse primeiro momento. Apenas desenvolva! Isso! Código “tosco” jogado na IDE mesmo (com moderação, claro)! Você verá que, ao final, quando for ajustar esse código “tosco” levando-se em consideração um melhor design e uma padronização de mais alto nivel, os testes que vc construiu irão te guiar para o sucesso.

Viu?! Simples como a definição de teste! Agora, deixa de ser frouxo e comece a desenvolver testes automatizados para as suas aplicações! Não sabe como? Bem, aguarde o próximo post então!

Até!

Comente e Recomende!

[edited]
Créditos ao meu grande amigo Filipe Paes pela descoberta
[/edited]

Como todos sabem, Metodologia Ágil se baseia muito em comunicação e em ter o cliente como membro da equipe. Também sabemos que membros de equipes ágeis não são muito chegados em diagramas e documentações extensas e muitas vezes sem sentido ou que não espelham realmente o que foi/será desenvolvido.

Alem disso, quando estamos em um ambiente de DDD, colocar uma linguagem “onipresente” (Ubiquitous Language) é o ponto alto para que o cliente consiga entender o que está sendo feito e como está sendo feito.

Com base nisso, criar uma sequência de informações rica o suficiente que possa guiar um desenvolvedor e em contrapartida  simples o suficiente para um cliente ler e entender é um problema. É? Não!!! Era!

Algum louco (rs) criou uma ferramenta (site?) chamada Web Sequence Diagrams, onde se consegue fazer uma breve sequencia informativa se transformar em um diagrama, ficando claro para o desenvolvedor e o cliente, técnico e leigo respectivamente.

Segue um exemplo para uma User Story de saque em um banco:

Cliente->Controle: Solicita saque
Controle->Fachada: Chama ação de Saque
Fachada->RepositorioContaCorrente: Verifica disponibilidade de saldo
RepositorioContaCorrente–>Fachada: Saldo é suficiente
Fachada->RepositorioContaCorrente: Decrementa saldo
RepositorioContaCorrente–>Fachada:
Fachada–>Cliente: Saque realizado!

note right of RepositorioContaCorrente: Acesso a dados omitido.

Simples não? Então, se vc jogar esse texto na ferramenta, aparecerá um quadro conforme a imagem abaixo:

Legal, não? Ele gera em tempo de execução uma imagem PNG editável.
Pronto! Em pouco tempo e com uma linguagem simples conseguimos atingir dois publicos diferentes dentro da mesma equipe.

Fica a dica!

O site da ferramenta é http://www.websequencediagrams.com/

Comente e Recomende!