Usando um Map<String, Object> para armazenar os parâmetros de um Managed Bean

Antes de escrever a segunda parte do artigo, vou apresentar o código do managed bean mencionado na seção de comentários do post anterior.

Na ocasião, o leitor Alessandro questionou os motivos de passar para os métodos create() e update() dos services um Map<String, Object> contendo os dados a serem persistidos ao invés da própria entidade. Respondi então que um desses motivos era a existência de um managed bean cujos atributos mapeados para a página JSF correspondente estavam contidos em um Map<String, Object> – onde a key é o nome do atributo e o value, seu valor – e assim seria mais fácil passá-lo para os services.

Sem mais delongas, segue o código (comentários javadoc removidos para torná-lo mais sucinto).

public abstract class ManagedBean {
	private Map<String, Object> parametros = new HashMap<String, Object>();

	protected final void definirParametros(String... nomesParametros) {
		for (String nome: nomesParametros) {
			parametros.put(nome, null);
		}
	}

	protected final void limparParametros() {
		for (String parametro: parametros.keySet()) {
			parametros.put(parametro, null);
		}
	}

	public final Map<String, Object> getParametros() {
		return parametros;
	}

	public final void setParametros(Map<String, Object> parametros) {
		this.parametros = parametros;
	}

	// Outros métodos omitidos.
}

Como usá-lo? Suponha que estamos construindo um managed bean responsável pelas operações de login do usuário (que contém os campos nome e senha). Ele pode ser implementado escrevendo-se o código abaixo:

public class LoginBean extends ManagedBean {
	public LoginBean() {
		// Definindo dois campos para a página de login.
		super.definirParametros("login", "senha");
	}

	public String efetuarLogin() {
		// A classe ApplicationServiceFactory foi apresentada no post anterior.
		Usuario usuario = ApplicationServiceFactory
			// Obtendo o service de usuário, que realizará o login.
			.getUsuarioService()
			// Passando diretamente o Map contendo os campos.
			.efetuarLogin(super.getParametros());

		// Restante do código omitido.
	}
}

Na página JSF correspondente a esse managed bean teríamos controles referenciando os parâmetros da seguinte forma:

<h:inputText value="#{loginBean.parametros['login']}" />
<h:inputText value="#{loginBean.parametros['senha']}" />

O ganho com essa abordagem aparece principalmente quando uma página possui muitos campos. Assim não precisa ficar replicando os atributos da entidade no managed bean, e nem mesmo usar a própria entidade - e se ver obrigado a usar getters e setters que expõem aqueles atributos que não seriam interessante expor. Sem contar que essa forma abre espaço para usar reflection para automatizar a passagem dos valores dos atributos para a entidade correspondente.

Quaisquer sugestões ou dúvidas podem ser apresentadas na seção de comentários.

Até lá!

Services, transações e proxies dinâmicos – parte I

Introdução

No primeiro semestre deste ano cursei uma disciplina na faculdade onde o trabalho final consistia em escrever um software usando apenas Hibernate e JSF. Desenvolvi então um software de gestão de transporte de cargas, que poderia ser comercializado para empresas que fazem uso de uma frota de veículos para realizar transportes rodoviários.

Falando um pouco sobre sua arquitetura, ele dispõe de uma camada de aplicação composta de serviços que são requisitados pela camada de apresentação – nesse caso, pelos managed beans. O código cliente conhece apenas a interface desse serviço, expressa no código abaixo:

interface EntityService<T, ID extends Serializable> {
    void create(Map<String, Object> parameters);
    Collection<T> readAll();
    T read(ID id);
    Collection readByParameters(Map<String, Object> parameters);
    void update(Map<String, Object> parameters);
    void delete(T t);
}

Cada serviço da camada deve ser expresso através de uma interface que estenda EntityService. Por exemplo, o código abaixo corresponde ao serviço de cadastro de veículos.

public interface VeiculoService extends EntityService<Veiculo, String> {
    // Declaram-se aqui outras operações requeridas por esse serviço.
}

A implementação desse serviço deve conter o corpo para todos os métodos declarados nas duas interfaces. Note que a mesma não precisa ser pública.

class VeiculoServiceImpl implements VeiculoService {
    // Fornece implementações para todos os métodos.
}

Há desvantagens nessa abordagem. Nem sempre é conveniente disponibilizar todos os serviços declarados em EntityService para uma determinada entidade. Por exemplo, e se algum requisito do projeto exigisse que não fosse possível alterar veículos? O código abaixo ilustra uma solução possível.

class VeiculoServiceImpl implements VeiculoService {
    // Não é possível alterar veículos.
    public void update(Map<String, Object> parameters) {
        throw new UnsupportedOperationException("Operação não permitida.");
    }
}

Porém, a discussão do que seria melhor ou não não está no escopo desse artigo, embora fosse interessante continuá-la na seção de comentários.

Finalmente, a classe abaixo é usada pela camada de apresentação para requisitar os serviços.

public class ApplicationServiceFactory {
    public static VeiculoService getVeiculoService() {
        return new VeiculoServiceImpl();
    }
}

Contexto transacional

A abordagem acima é interessante, mas as operações de cada serviço não são executadas sob contexto transacional. Isto é, se tivermos uma operação que precise realizar duas ou mais instruções de persistência de dados, uma eventual falha ocorrida em uma dessas instruções não cancela as anteriores. Isso pode acarretar em estado inconsistente dos dados. Precisamos então aplicar uma solução que permita que as operações dos serviços executem sob contexto transacional.

Há várias soluções para o problema:

• Usar Spring;
• Escrever um aspecto;
• Usar o padrão Proxy.

O objetivo deste artigo é explorar o padrão Proxy e a API de proxies dinâmicos do Java para aplicar um contexto transacional para todos os serviços da aplicação. Será o que desenvolveremos na parte 2.

Até lá!

Passagem explícita de tipos para métodos genéricos em Java

Quando temos uma classe genérica em Java, precisamos sempre passar de forma explícita o tipo do parâmetro genérico. O uso da classe ArrayList<E> exemplifica isto.

List<Usuario> l = new ArrayList<Usuario>();

Aqui estamos indicando explicitamente que a nossa lista contém apenas instâncias da classe Usuario.

Problema

Quando criamos métodos genéricos, geralmente declaramos argumentos na assinatura do método que permitem ao compilador inferir o tipo genérico, sem que precisemos indicar de forma explícita. Como exemplo, temos o método Collections.copy() da API do Java que copia elementos de uma collection para outra. A declaração do método é:

public static <T> void copy(List<? super T> dest, List<? extends T> src) {
    // Copia os elementos de src para dest,
}

Se usarmos o método da seguinte forma:

List<Usuario> lista1 = new ArrayList<Usuario>();
List<Usuario> lista2 = new ArrayList<Usuario>();
Collections.copy(lista1, lista2);

Damos condições para que o compilador deduza, a partir do tipo dos argumentos dest e src, que T representa instâncias da classe Usuario. Mas há situações em que isso não é possível, como no método abaixo:

public class FabricaDeListas {
    public static <T> List<T> criarNovaListaDeQualquerCoisa() {
        return new ArrayList<T>();
    }
}

Aqui o compilador não dispõe de argumentos no método para tentar inferir o tipo T. Precisamos passar de forma explícita, assim como fazemos com classes. Mas como fazer isso?

Solução

A página 86 do livro Java Precisely (2ª edição, 2005), na seção 21.8 – Generic Methods, indica a sintaxe da linguagem para resolver o problema:

Classe.<Tipo1, Tipo2, ..., TipoN>metodoEstatico(); // Para métodos estáticos
instancia.<Tipo1, Tipo2, ..., TipoN>metodo(); // Para métodos de instância.

Ou seja, tomando o exemplo anterior, podemos escrever:

List<Usuario> = FabicaDeListas.<Usuario>criarNovaListaDeQualquerCoisa();
List<Cachorro> = FabicaDeListas.<Cachorro>criarNovaListaDeQualquerCoisa();

E assim sucessivamente. Notem que é preciso indicar de forma explícita a entidade que invoca o método, seja uma classe ou um objeto.

Configurando ambiente JRuby on Rails + SQLite3 no Windows

JRuby é uma implementação da linguagem Ruby escrita 100% em Java que oferece total suporte a Ruby on Rails. O objetivo deste tutorial é configurar um ambiente de desenvolvimento Ruby on Rails no Windows utilizando JRuby e o banco de dados SQLite3. Apesar de ter sido escrito especificamente para Windows, ele pode ser facilmente adaptado para outras plataformas.

No momento da publicação deste tutorial as versões das tecnologias envolvidas eram:

• Java – JDK 6 update 14
• JRuby – 1.3.1
• Ruby on Rails – 2.3.3
• SQLite3 – 3.6.17

Vamos lá:

Passo 1 – baixe o JDK diretamente do site da Sun e instale-o conforme recomendado, criando a variável de ambiente JAVA_HOME que aponta para o diretório de instalação e adicionando o caminho %JAVA_HOME%\bin ao PATH.

Passo 2 – baixe o JRuby clicando no link Download e selecionando a versão mais atual. Descompacte o arquivo em um local de sua preferência. Crie uma variável de ambiente JRUBY_HOME que aponta para esse local e adicione o caminho %JRUBY_HOME%\bin ao PATH.

Passo 3 – Entre no site do SQLite3 e clique no link Download. Na seção “Precompiled Binaries for Windows” baixe os arquivos sqlite-<VERSÃO>.zip e sqlitedll-<VERSÃO>.zip (conforme dito anteriormente, a versão contemporânea a este tutorial é a 3.6.17). Crie um diretório no local de sua preferência denominado sqlite3. Descompacte os arquivos .zip baixados dentro desse diretório e configure a variável PATH para apontar para ele.

Passo 4 – Vamos testar o que instalamos até agora. Abra um prompt de comando e digite:

jruby -v

A versão do JRuby instalada no seu computador deve aparecer na tela. Digite agora a linha:

sqlite3

O SQLite3 será executado e ficará aguardando a entrada de comandos de administração. Digite “.exit” sem as aspas para sair do SQLite3.

Passo 5 – Vamos agora instalar o Rails. Abra o prompt de comando, digite a linha:

jruby -S gem install rails

e aguarde até o final da instalação. Quando ela terminar, digite:

jruby -S rails -v

para visualizar a versão do Rails instalada.

OBS: o parâmetro -S força o JRuby a procurar o script dentro da pasta “bin” ou na variável de sistema PATH.

Passo 6 – Precisamos instalar também o driver do SQLite3 para o JRuby. Isso pode ser feito digitando a seguinte linha no prompt de comando e pressionando ENTER:

jruby -S gem install activerecord-jdbcsqlite3-adapter

Lembrando de aplicar as configurações de proxy conforme visto anteriormente, caso necessário.

Passo 7 – Finalmente, criaremos uma aplicação de exemplo para testarmos o ambiente. Navegue pelo prompt de comando até o diretório onde você mantém suas aplicações e digite:

jruby -S rails teste

Edite o arquivo “config\database.yml” com a ajuda de um editor de textos. Na configuração do ambiente de desenvolvimento, altere o valor da propriedade “adapter” para “jdbcsqlite3″.

Entre no diretório “teste” e digite a seguinte linha para criar um cadastro de pessoas:

jruby script/generate scaffold Person name:string phone:string

Crie o banco de dados:

rake db:migrate

Inicie o servidor:

jruby script/server

E acesse o endereço “http://localhost:3000/people”. Se tudo deu certo, você verá a página que mostra as pessoas cadastradas no sistema.

IMPORTANTE: se a rede onde está seu computador possui configuração de proxy, é preciso passar essa configuração através do parâmetro -p do comando gem usando a seguinte sintaxe:

-p http://usuario:senha@servidorproxy:porta

Isso deve ser feito para todos os comandos de instalação de gems que foram vistos nesse tutorial. Use o seguinte exemplo como referência:

jruby -S gem install rails -p http://tarso:123@meu.proxy.com.br:4321

Quaisquer dúvidas e/ou correções, favor postar nos comentários. Até mais!

Oxente Rails – Dia 2

Antes de prosseguir, leia: http://cabritin.wordpress.com/2009/08/11/oxente-rails-dia-1/

Após um surpreendente primeiro dia, era difícil de imaginar que o segundo seria ainda mais empolgante.

Palestras

Ao contrário do primeiro post, não vou citar as palestras na ordem em que ocorreram porque já não me lembro direito Quero agradecer ao meu amigo Jean por ter me deixado usar seu MacBook para fazer alguns tweets durante o dia, valeu Jean!

As boas vindas começaram com cerca de uma hora de atraso, talvez consequência da comemoração do dia anterior. O primeiro palestrante mostrou como seu site desenvolvido em Ruby on Rails pode ser integrado ao PagSeguro, um sistema de pagamento on-line que foi inclusive utilizado pelos organizadores do evento para processar os pagamentos dos participantes.

A partir daqui as palestras não seguiram mais o roteiro original. Não ficaram claros os motivos, e no final das contas ninguém se importou, porque os organizadores conseguiram lidar com o imprevisto com maestria e aplicaram a essência da metodologia ágil para reorganizar o roteiro e criar novas atividades!

Durante a manhã o Tapajós e o Mergulhão realizaram mais uma “pair presentation” que estava originalmente programada para a sexta, cujo objetivo era mostrar um cenário real de escalabilidade de um sistema Rails – o RedeParede, um sistema de classificados on-line – para mandar para a cucuia de uma vez por todas esse boato de que Rails não escala, que já se tornou um mantra repetido por aqueles que ainda mantém o ceticismo em relação à tecnologia.

Devido à controvérsia Twitter, já tinha chegado a pensar que não era fácil escalar um sistema desenvolvido em Rails. Porém os palestrantes mostraram que não é tão diferente de escalar um software escrito em outra plataforma. Provaram por A + B que é totalmente viável. Tive também a oportunidade de tirar uma dúvida com eles sobre a implementação Ruby que eles usavam pra rodar os application servers.

O Dante Régis realizou a sua palestra mostrando formas de efetuar deploy de aplicações Rails, ilustrando através do seu dia a dia no Tribunal de Justiça de Sergipe, onde ele trabalha. Sua participação na adoção de Ruby on Rails na instituição deve servir como exemplo de que é possível usar a tecnologia em locais com muita formalidade e burocracia.

Tarde

No sábado decidi não almoçar no local do evento, pois percebi que uma galera ia almoçar no Midway e eu não queria perder a oportunidade de me entrosar com o pessoal. Dos palestrantes, consegui conversar um pouco com o Mergulhão e devo dizer que me surpreendi com sua simplicidade. Consegui fazer amizade com outros participantes também.

Não lembro direito a ordem como as coisas aconteceram durante a tarde, então desculpem se estou citando os eventos fora da sequência. Só sei que a primeira palestra foi um vídeo de Geoffrey Grosenbach sobre seus três anos de Peep Code. Não assimilei absolutamente nada pelo mesmo motivo do dia anterior: bucho cheio. Dessa vez agravado pelo fato da palestra ser em inglês e meu aparelhinho para acompanhar a tradução estar com mal contato no fone de ouvido.

Jogo de comunicação

O primeiro ponto alto da tarde foi o jogo de comunicação organizado pelos palestrantes e trazido para o evento por Tapajós e outros. O público foi dividido em duas equipes, cada uma subdividida em dois grupos que chamarei de A e B. Na primeira rodada, o grupo A de cada equipe tomou posse de dois desenhos e ficou com a responsabilidade de passar dicas sobre os mesmos para o grupo B através de pequenos papéis escritos; este deveria tentar reproduzí-los baseando-se unicamente nas descrições, sem qualquer outra forma de comunicação.

Ao final da primeira rodada os resultados finais foram apresentados, e o esperado aconteceu: a reprodução ficou bastante distorcida em relação ao original. Então os organizadores do jogo aplicaram algumas práticas de agilidade e instituiram que cada equipe deveria analisar as causas que acarretaram na distorção e corrigí-las. Uma vez levantados os pontos falhos – e enumeradas as sugestões para lidar com eles – era hora de iniciar a segunda rodada, mas dessa vez os papéis dos grupos foram trocados: o grupo B tomou posse dos desenhos enquanto o grupo A ficou de tentar reproduzí-los. Dessa vez uma das equipes, a que estava situada no auditório, mostrou sua capacidade de autocorreção e conseguiu confeccionar uma reprodução bastante fiel à original. Já o desempenho nessa etapa da equipe que ficou no palco foi pior do que na primeira…

E adivinham em qual equipe eu estava? A do palco Tivemos que usar chapéu de palhaço durante toda a palestra que se seguiu hehe.

Mas tudo bem, eu estava muito feliz por ter participado da experiência – e também por ter sido sorteado com um livro de REST sobre Rails!

Etapa final

Após um rápido coffe-break, tivemos o segundo ponto alto da tarde: uma “mesa redonda” com os palestrantes, onde todos eles foram colocados diante do público do evento para uma conversa frente a frente sobre temas relacionados – ou não – ao evento e ao mundo Rails. Muito interessante o fato de que todos eles se sentaram à frente do palco, fazendo-nos esquecer a hierarquia palestrante-espectador e trazendo um tom de informalidade. As perguntas eram realizadas pelo microfone ou via Twitter – a página do Twitter do evento foi exibida no telão e os participantes podiam interagir em tempo real.

A penúltima palestra foi uma das que eu mais estava esperando. Paulo Fagiani falou um pouco sobre JRuby e toda a integração Java-Ruby que a implementação proporciona. Eu como desenvolvedor Java particularmente estudo Rails em casa rodando tudo sobre o JRuby e deployando nos servidores de aplicação disponíveis para a plataforma Java.

E a última palestra seguiu um modelo mais informal mas não menos agradável. Jon Larkowski apresentou-nos seu dia a dia como desenvolvedor da Hashrocket num tom bastante irreverente. Ele dissecou o manifesto ágil categorizando as práticas do XP de acordo com a semântica de cada linha e mostrou o “Hashrocket way” de fazer as coisas Foi a única palestra internacional que consegui acompanhar sem o aparelhinho que transmitia a tradução. Pudemos também ver algumas fotos do ambiente de trabalho e de sua estadia na Cidade do Sol.

O evento novamente esticou para um Hora Extra. Eu novamente não fui. Shame on me

Considerações finais

O evento foi um sucesso. Simples assim. A comunidade Rails natalense mostrou sua força. Parabéns aos organizadores pela qualidade ímpar do evento, parabéns aos palestrantes pelo alto nível. E claro, parabéns a nós participantes pois “sem nosco” não haveria evento

Até o próximo Oxente Rails!

Oxente Rails – Dia 1

Eu vinha notando que há alguns meses atrás uma comunidade Ruby on Rails aqui em Natal estava ganhando força. Minhas suspeitas se confirmaram: o Oxente Rails, um excelente evento sobre o framework do momento Ruby on Rails, foi realizado no IFRN – antigo CEFET – neste último fim de semana, dias 07 e 08 de agosto. Não lembro agora como soube do evento, mas entrei no site e me surpreendi tanto com as empresas que estavam apoiando quanto com a lista de palestrantes, que incluía nomes como Yehuda Katz, Fábio Akita, Marcos Tapajós e Carlos Brando.

De cara percebi que o evento seria muito bom, e como pra mim sempre foi muito difícil ir a eventos como o Rails Summit, então concluí que não poderia deixar de presenciar este.

Uma coisa que me deu má impressão no início foi durante a inscrição. Quando imprimi o boleto via PagSeguro e efetuei o pagamento, fiquei aguardando um e-mail de confirmação de inscrição que só veio na véspera do evento. Mas sem problema, preenchi o formulário de contato do site e não demorou para o Elomar França – um dos organizadores – me responder via e-mail que bastaria eu comparecer no dia do evento para credenciamento.

Palestras – 1ª etapa

Passado algum tempo, chegou o primeiro dia. Recebimento de crachá, materiais, realização de boas vindas… E então começou a primeira palestra, ministrada pelo renomado evangelista Rails Fábio Akita. Uma apresentação excelente, dinâmica e com bastante informação sobre o mundo Rails, tanto que é provável que algumas pessoas não tenham assimilado tanta informação em tão pouco tempo – eu fui uma delas.

Então começou a segunda palestra, uma interessantíssima e irreverente apresentação feira pelo railer e aspirante a mágico Carlos Brando. Ele palestrou sobre Ruby e a mágica por trás da metaprogramação. Infelizmente quem não tinha um pouco de noção da linguagem acabou voando. Depois tivemos um pouco de BDD na prática através da apresentação do instrutor da Caleum Cauê Guerra – inclusive vi um tweet do Fábio Kung dizendo que ele fez aniversário esse fim de semana, parabéns!

Palestras – 2ª etapa

Pausa para o almoço, com direito a suco e sanduíches. O sono típico de início de tarde provocado pelo bucho cheio prejudicou minha atenção na palestra seguinte: Juarez Filho falou sobre design de interfaces, mas não assimilei absolutamente nada. Depois fomos apresentados pelo professor do IFPI Régis Pires ao Easy Rails, que consiste em uma forma interessante e fácil de usar o Rails em ambientes Windows e Linux.

Então tivemos a primeira grande surpresa do evento: a palestra de desenvolvimento ágil, que seria apresentada no dia seguinte, foi antecipada. Ministrada por Marcos Tapajós e Sylvestre Mergulhão, foi a primeira “pair presentation” que vi. Tive oportunidade de tirar duas dúvidas sobre a adoção de métodos ágeis no lugar onde trabalho com esses monstros da agilidade. Muito obrigado aos palestrantes pelas respostas.

A palestra final era uma das que eu mais esperava: Rails 3, por nada mais nada menos que um dos membros do time de desenvolvimento, Yehuda Katz. Infelizmente, não consegui acompanhar pois não entendo muito inglês de ouvido – apesar de ler fluentemente – e não consegui acompanhar a tradução simultânea. Que pena.

Houve então a seção de desconferência, onde alguns participantes tiveram oportunidade de palestrar sobre temas específicos. E assim encerrou-se o primeiro dia, que esticou para um “hora extra” no bar da Saideira. Eu tive que ir à aula e infelizmente não pude comparecer; hoje estou muito arrependido, pois perdi a oportunidade de conhecer gente nova e engajada na área.

Ao final eu estava em êxtase. O primeiro dia foi, para mim e para muitos, mais do que o esperado. Mas o segundo dia ainda seria melhor… Aguardem resenha em breve! Até mais.

Feliz 2009!

Faltam pouco menos de duas horas para o ano novo. Estou em casa reunido com minha família, mas passei aqui no computador para escrever.

Como devem ter percebido, este blog está bastante abandonado. Gostaria de levar mais a sério o ato de blogar, mas eu nem escrevo muito e nem divulgo muito este blog. Vamos ver se mudo isso em 2009.

Há mais ou menos um ano atrás, escrevi sobre minhas metas “nerds” para 2008. Vamos ver o que fiz e o que não fiz:

• Meta 1: aprender Hibernate – não aprendi da forma como gostaria, que seria lendo o livro Java Persistence With Hibernate. Acabei aprendendo na marra, mexendo nos sistemas do trabalho;
• Meta 2: aprender JSF – idem item anterior, com a diferença que não aprendi o suficiente pra desenvolver uma aplicação do zero. Não por preguiça, mas sim porque acabei conhecendo outros frameworks bem mais interessantes, como o Wicket;
• Meta 3: estudar design patterns – sim! Li (quase) todo o livro Head First Design Patterns. Recomendado;
• Meta 4: ler o livro de Martin Fowler sobre padrões arquiteturais – nem cheguei perto desse livro…
• Meta 5: estudar Test-Driven Development – acabei estudando TDD por tabela, quando estudei um pouco de XP. Mas não cheguei a por em prática;
• Meta 6: estudar Domain-Driven Design – sim! Estudei bastante esse assunto e tentei aplicá-lo o máximo que pude nos projetos da faculdade que desenvolvi. No trabalho, infelizmente não tenho a liberdade que gostaria para utilizá-lo;
• Meta 7: Ruby – sim! Estudei bastante Ruby esse ano, e cheguei a utilizá-lo em algumas tarefas importantes no trabalho.

O balanço foi bom, apesar de não ter feito tudo. E quais as metas nerds pra 2009?

• Terminar os cursos de JRuby On Rails e de JEE do site JavaPassion;
• Ler o livro de Domain Specific Languages de Martin Fowler, que está prestes a ser lançado;
• Aplicar Ruby On Rails em algum projeto;
• Estudar bastante metodologias ágeis (XP e Scrum);
• Aprofundar e fixar mais os conhecimentos em Ruby através da leitura do livro do Why (o original ou a tradução);
• Estudar REST
• E, se der tempo, cumprir as metas de 2008 pendentes

É isso! Feliz ano novo para todos nós!

OO em Delphi

A linguagem Delphi (a linguagem, não a ferramenta) tem muitos recursos interessantes, dentre eles total suporte à orientação a objetos. Porém, muitos programadores Delphi não os utilizam por desconhecimento. Percebo que o ensino em Delphi nas faculdades e cursos técnicos sempre foi bastante alienante, com foco na ferramenta, e não na linguagem.

Desde cedo somos habituados a arrastar componentes e programar eventos, sem sequer olharmos o código que a ferramenta gera, tampouco entendê-lo. E o pior é que isso é suficiente para programarmos sistemas completos na plataforma – não necessariamente com qualidade, claro. O resultado, muitas vezes, é um software difícil de manter, com mistura de código que trata de lógica de apresentação, negócios e persistência.

A partir de agora, pretendo escrever neste blog uma série de artigos ilustrando os recursos OO que a linguagem Delphi oferece, traçando um paralelo com outras linguagens (principalmente Java, mas quando conveniente, Ruby ou JavaScript). Não há um roteiro de publicação definido; os temas serão avulsos, abrangendo as mais variadas características de uma boa linguagem OO, como encapsulamento, polimorfismo, padrões de projeto, etc.

Para você que sempre programou em Delphi de maneira tradicional, esses conceitos poderão ser úteis para abrir sua mente, assim como abriram a minha.

Drawspace: curso on-line de desenho gratuito

Desenterrando este blog para uma notícia boa.

Há muito tempo atrás eu costumava desenhar, mas parei no tempo. Ultimamente venho pensando em voltar, então procurei no Google algum curso de desenho. Acabei achando este excelente site, que dispõe de mais de 300 lições devidamente categorizadas para Iniciante, Intermediário e Avançado.

Segue o link:

http://www.drawspace.com/

Enrolação de dependências – parte III

Finalmente, a parte final deste artigo!

Antes de prosseguir, leia: http://cabritin.wordpress.com/2008/03/07/enrolacao-de-dependencias-parte-ii/

Observe novamente a figura publicada na parte 1:

O diagrama ilustra uma relação um-para-muitos entre empresa e funcionário, este podendo ser um gerente ou um empregado.

Vamos traduzir este diagrama em um pouco de código. Inicialmente, poderíamos implementá-lo da seguinte maneira:

public class Empresa {
    private List<Funcionario> funcionarios;

    public Empresa() {
        funcionarios = new ArrayList<Funcionario>();
    }

    public void addGerente() {
        funcionarios.add(new Gerente()); // Linha 9
    }

    public void addEmpregado() {
        funcionarios.add(new Empregado()); // Linha 13
    }
}

public interface Funcionario {

}

public class Empregado implements Funcionario {
    // Construtores, atributos, métodos, etc
}

public class Gerente implements Funcionario {
    // Construtores, atributos, métodos, etc
}

Há algum problema nessa implementação? Aparentemente, não. Ela está bonitinha, usando polimorfismo, inversão de dependências (lembra o que é?) e tudo o mais. Mas veja só: a classe Empresa está instanciando diretamente as classes Gerente e Empregado (linhas numeradas). Tá, mas e qual o problema nisso? Ora, simples: se por acaso os construtores dessas classes mudarem, precisaremos modificar também as linhas 9 e 13. Agora, imagine se eu tivesse 50 classes, todas dependendo de Empregado e Gerente! Ia sobrar pro estagiário fazer a modificação em todas elas…

Mas vamos facilitar a vida do estagiário. Vamos tentar aplicar Inversão de Controle à situação.

O que queremos, então? Queremos evitar que Empresa instancie Empregado e Gerente diretamente; queremos diminuir o acoplamento entre as classes. A criação das instâncias é a responsabilidade que queremos inverter, ou seja, deixar para outra entidade fazê-lo.

Resumindo: a classe Empresa não mais criará as instâncias; ela as receberá já criadas. Como? Através dos métodos addEmpregado() e addGerente(). Vamos modificá-la então!

public class Empresa {
    private List<Funcionario> funcionarios;

    public Empresa() {
        funcionarios = new ArrayList<Funcionario>();
    }

    public void addFuncionario(Funcionario f) {
        funcionarios.add(f);
    }
}

Nossa! A classe Empresa ficou totalmente independente dos tipos concretos de Funcionario. Ela nem sabe mais que eles existem! O código cliente que utilizar as classes de domínio usará a classe como se segue:

Empresa e = new Empresa();
e.addFuncionario(new Gerente());
e.addFuncionario(new Empregado());

Ou seja, os funcionários são agora injetados dentro da empresa através do método addFuncionario(). Espere um pouco, você disse injetados?

Sim. Utilizamos um método que serve para passarmos para a (injetarmos na) classe Empresa as instâncias (dependências) de que ela precisa – neste caso, os funcionários de uma empresa. Invertemos o controle da instanciação dos objetos para o código cliente. Isto é injeção de dependências.

Há outras formas de injetar dependências em uma classe, como por exemplo fazê-lo por meio de um construtor (passando a dependência como argumento). E há também outras formas de instanciar os objetos de que sua aplicação precisa: frameworks como o Spring e o PicoContainer implementam containers que cuidam do processo de instanciação. Se não quiser utilizar um desses containers, um Factory Method resolve seu problema muito elegantemente.

Para encerrar, sugiro fortemente que você leia o artigo do Martin Fowler sobre o assunto. Estes posts não têm a intenção de substituí-lo: serve apenas para dar uma idéia geral.

Até mais.