Porém essa atualização iria modificar uma parte da codificação do post então decidimos criar um novo focando somente em Spring 3.1 e Hibernate 4.0.

Aos que estão iniciando neste assunto, sugiro a leitura dos assuntos abordados em posts anteriores:

• Spring Framework Parte 1 -> Dependency Injection
• Spring Framework Parte 2 -> Aspect Oriented Programming
• Spring Framework Parte 3 -> Java Database Connectivity (JDBC)

Neste tópico vamos abordar a configuração de um projeto utilizando Hibernate 4 com anotações (annotations), Spring 3.1 e uma base de dados MySQL.

Usar Annotations ou XML?

Existe muita discussão sobre este assunto. O Hibernate permite as duas formas, ambas tem suas vantagens e desvantagens.

Na minha opnião o Annotations tem grande vantagem pois elimina arquivos para cada mapeamento, aumenta a produtividade pela configuração ficar diretamente no POJO, ou seja, na classe java que representa a tabela que está sendo mapeada.

Uma das maneiras mais diretas de interagir com banco de dados usando o Java é via JDBC, porém exige muita codificação para manter os dados persistentes no sistema. Atualmente temos ferramentas como o Hibernate que nos auxiliam neste trabalho e que está evoluindo constantemente para ficar ainda melhor.

Bom, chega de papo, vamos codificar!

Vamos criar no Eclipse um novo Java Project chamado Spring_HibernateAnnotations.

Bibliotecas e Dependências

Criarei no projeto uma pasta lib e colocarei dentro as bibliotecas necessárias para rodar o Spring 3.1 e o Hibernate 4.0. As bibliotecas podem ser encontradas em:

• Spring: http://www.springsource.org/download (todos os arquivos da pasta dist)
• Hibernate: http://sourceforge.net/projects/hibernate/files/hibernate4/ (todos os arquivos da pasta lib/required e lib/jpa)

O Spring e o Hibernate fazem uso de bibliotecas auxiliares que precisarão ser adicionadas:

• Commons Logging: http://commons.apache.org/logging/ (extraia e adicione somente o commons-logging-1.1.1.jar)
• SLF4J: http://www.slf4j.org/download.html (adicione somente slf4j-api-1.6.x.jar e slf4j-simple-1.6.x.jar)
• JTA: http://repo2.maven.org/maven2/javax/transaction/jta/1.1/ (adicione somente jta-1.1.jar)
• AspectJ http://www.eclipse.org/aspectj/downloads.php (Extraia o aspectj-1.x.x .jar com o Winrar e adicione em seu projeto os arquivos da pasta lib)
• AOPAlliance http://aopalliance.sourceforge.net/ (Adicione o aopalliance.jar)

Para conectar com a base de dados MySQL precisamos também do conector:

• Connector J: http://dev.mysql.com/downloads/connector/j/ (Adicione o mysql-connector-java-x.x.x-bin.jar)

Após adicionar os jars ao projeto devemos ter uma tela parecida com essa:

Mãos à obra

Vamos definir uma estrutura inicial de pacotes para o nosso projeto:

• conf: Guardará o arquivo de configurações
• spring_hibernateannotations:  Local onde ficarão as classes que farão execução
• spring_hibernateannotations.interfaces: Guardará as interfaces
• spring_hibernateannotations.modelo: Guardará os POJOs

Arquivo de configuração

Vamos criar o arquivo de configuração do Spring com o nome conf.xml no pacote conf:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
 
	<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName" value="com.mysql.jdbc.Driver" />
		<property name="url" value="jdbc:mysql://localhost/hibernate_teste" />
		<property name="username" value="root" />
		<property name="password" value="root" />
	</bean>
 
	<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="annotatedClasses">
			<list>
				<value>spring_hibernateannotations.modelo.Livro</value>
			</list>
		</property>
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
				<prop key="hibernate.show_sql">true</prop>
			</props>
		</property>
	</bean>
 
	<bean id="banco_dados" class="spring_hibernateannotations.BancoDados">
		<property name="sessionFactory" ref="sessionFactory" />
	</bean>
 
</beans>

CREATE TABLE  'Livros' (
    'liv_cod' INT NOT NULL ,
    'liv_titulo' VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL ,
    PRIMARY KEY (  'liv_cod' )
) ENGINE = INNODB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

@Entity
@Table(name = "livros")
@GenericGenerator(name = "mygenLivros", strategy = "increment")
public class Livro implements Serializable {
 
	private static final long serialVersionUID = 6216997659936884192L;
 
	@Id
	@GeneratedValue(generator = "mygenLivros")
	@Column(name = "liv_cod")
	private int cod;
 
	@Column(name = "liv_titulo")
	private String titulo;
 
	// Getters e Setters
 
}

public interface IBanco {
 
	public Livro InserirLivro(Livro livro);
 
	public void AtualizarLivro(Livro livro);
 
	public void ApagarLivro(Livro livro);
 
	public List<Livro> SelecionarLivrosPorTitulo(String titulo);
 
	public Livro SelecionarLivroPorCodigo(int cod);
 
}

public class BancoDados implements IBanco {
 
	private SessionFactory sessionFactory;
 
	private Session sessao;
 
	private Transaction transacao;
 
	public void setSessionFactory(SessionFactory sessionFactory) {
		this.sessionFactory = sessionFactory;
		this.sessao = sessionFactory.openSession();
	}
 
	public Livro InserirLivro(Livro livro) {
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			int cod = (Integer) sessao.save(livro);
			transacao.commit();
			livro.setCod(cod);
		}
		catch(HibernateException e) {
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e)
			{
				System.out.println("Erro ao finalizar inserção: " + e.getMessage());
			}
		}
 
		return livro;
 
	}
 
	public void AtualizarLivro(Livro livro) {
 
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			sessao.update(livro);
			transacao.commit();
		}
		catch(HibernateException e)
		{
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e){
				System.out.println("Erro ao finalizar atualização: " + e.getMessage());
			}
		}
 
	}
 
	public void ApagarLivro(Livro livro) {
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			sessao.delete(livro);
			transacao.commit();
		}
		catch(HibernateException e) {
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e) {
				System.out.println("Erro ao finalizar : " + e.getMessage());
			}
		}
	}
 
	public List<Livro> SelecionarLivrosPorTitulo(String titulo) {
		if(!sessao.isOpen()) {
			sessao = sessionFactory.openSession();
		}
		Criteria criteria = sessao.createCriteria(Livro.class);
		criteria.add(Restrictions.like("titulo", titulo));
		return criteria.list();
	}
 
	public Livro SelecionarLivroPorCodigo(int cod) {
		if(!sessao.isOpen()) {
			sessao = sessionFactory.openSession();
		}
		Criteria criteria = sessao.createCriteria(Livro.class);
		criteria.add(Restrictions.eq("cod", cod));
		Livro livro = (Livro) criteria.uniqueResult();
		return livro;
	}
 
}

public class Main {
 
	public static void main(String[] args) {
 
		ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/conf.xml");
		System.out.println("Spring inicializado");
 
		BancoDados banco = (BancoDados) ctx.getBean("banco_dados");
 
		Livro livro1 = new Livro();
		livro1.setTitulo("Spring + Hibernate");
		Livro livro2 = new Livro();
		livro2.setTitulo("Hibernate Avançado");
		System.out.println("Objetos Livro inicializados");
 
		livro1 = banco.InserirLivro(livro1);
		livro2 = banco.InserirLivro(livro2);
		System.out.println("Livros gravados no banco");
 
		//zerando os objetos Livro
		livro1 = null;
		livro2 = null;
 
		System.out.println("Selecionando livros por código");
		livro1 = banco.SelecionarLivroPorCodigo(1);
		exibe(livro1);
		livro2 = banco.SelecionarLivroPorCodigo(2);
		exibe(livro2);
 
		System.out.println("Selecionando livros que contenham 'Hibernate' no título");
		List<Livro> lista = banco.SelecionarLivrosPorTitulo("Hibernate");
		for (Livro l : lista){
			exibe(l);
		}
 
		System.out.println("Atualizando livro");
		livro1.setTitulo(livro1.getTitulo()+" Segunda Edição");
		banco.AtualizarLivro(livro1);
 
		System.out.println("Apagando livro");
		banco.ApagarLivro(livro2);
	}
 
	public static void exibe(Livro livro) {
		if (livro == null)
			System.out.println("Livro não encontrado");
		else
			System.out.println("Livro -> cod: " + livro.getCod() + " | Título: " + livro.getTitulo());
	}
 
}

Bem legal, já vimos que funciona e funciona muito bem desse jeito.

Porém, – sempre tem um porém hehe –  conforme o sistema vai começando a crescer os arquivos de configuração começam a se tornar verdadeiras teias de aranha. Crescem muito!

E como a ideia do Spring é simplificar ao invés de complicar existe um jeito alternativo aos arquivos XML para configurar a injeção de dependência nos nossos beans: anotações.

Utilizando simples anotações nós conseguimos deixar o(s) arquivo(s) de configuração do Spring o mais simples possível e ainda assim deixar o container cuidar da injeção de dependência.

NOSSA APLICAÇÃO

Vamos desenvolver um pequeno programa para simular o funcionamento de um computador então.

O projeto vai ter a seguinte estrutura:

OBS: a pasta lib contém todas as bibliotecas necessárias para rodar o projeto.

Vamos começar dando uma olhada no pacote br.blog.javasimples.spring.pecas para vermos as interfaces que definem as pecas do computador:

/**
 * Interface que define os métodos necessários para uma peça do computador.
 * 
 * @author Felipe
 */
public interface Peca {
 
	void ligar();
 
}

/**
 * Interface que define os métodos necessários para um Monitor.
 * 
 * @author Felipe
 */
public interface Monitor extends Peca {
 
	/**
	 * Escreve uma mensagem na tela.
	 */
	void escreverNaTela(String mensagem);
 
}

/**
 * Interface que define os métodos necessários para um Processador.
 * 
 * @author Felipe
 */
public interface Processador extends Peca {
 
	/**
	 * Soma dois inteiros.
	 */
	int soma(int x, int y);
 
}

Vamos dar uma olhada em como as implementações dessas interfaces funcionam (pacote br.blog.javasimples.spring.pecas.impl):

/**
 * Classe que representa um monitor CRT de 17 polegadas.
 * 
 * @author Felipe
 */
public class Monitor17 implements Monitor {
 
	private final int FREQUENCIA = 60;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[" + mensagem + "]");
	}
 
}

/**
 * Classe que representa um processador DualCore.
 * 
 * @author Felipe
 */
public class DualCore implements Processador {
 
	private final double FRQUENCIA = 2.6;
 
	private final int NUCLEOS = 2;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o processador [" + FRQUENCIA + "GHz, " + NUCLEOS + " núcleos];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public int soma(int x, int y) {
		return x + y;
	}
}

Cada implementação é específica de um produto, ou seja, temos um monitor CRT de 17” que só suporta 60Hz e um processador DualCore (Intel) cuja frequência é 2.6GHz.

E o computador? Como fica?

/**
 * Classe que representa o computador.
 * 
 * @author Felipe
 */
public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	public void ligar() {
		System.out.println("Ligando computador...");
		processador.ligar();
		monitor.ligar();
		System.out.println("Computador ligado.");
	}
 
	public void somar(int x, int y) {
		monitor.escreverNaTela(String.format("%d + %d = %d", x, y, processador.soma(x, y)));
	}
 
}

O computador foi escrito seguindo as melhores práticas de desenvolvimento conforme já conversamos na  Parte 1 da série né:

• Programação orientada a interfaces e não a implementações: perceba que o computador não sabe se na sua placa mãe tem um processador Intel ou AMD, ele só sabe que tem um processador que sabe como ligar e somar;
• Injeção de dependência: perceba que todas as dependências do computador são injetadas nele através do seu construtor, com isso ganhamos muita flexibilidade para futuras mudanças em relação a quais componentes devemos injetar no computador.

E o arquivo de configuração ficou da seguinte maneira:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador">
		<constructor-arg name="monitor" ref="monitor" />
		<constructor-arg name="processador" ref="processador" />
	</bean>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
</beans>

public class Main {
 
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext("br/blog/javasimples/spring/config/applicationContext.xml");
		Computador pc = (Computador) context.getBean("computador");
		pc.ligar();
		pc.somar(2, 2);
	}
 
}

O que acontece nela é que criamos o container do Spring a partir do arquivo de configuração, ligamos o computador e realizamos uma simples operação nele. Ao executar essa classe nós recebemos a seguinte saída:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [60Hz];
Computador ligado.
[2 + 2 = 4]

Legal, tudo funciona como nós já estávamos acostumados.

Preparando o container

Por padrão o container do Spring não vem com o suporte para injeção de dependência via anotações habilitado. Para fazer isso nós precisamos fazer uma pequena alteração no arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
</beans>

E como vamos utilizar a injeção de dependência via anotações nós já podemos remover as injeções declarativas do arquivo de configuração.

O Spring suporta algumas anotações para a injeção de dependência, são elas:

• A anotação do próprio Spring Framework @Autowired;
• A anotação @Inject da JSR-330 (Dependency Injection for Java);
• A anotação @Resource da JSR-250 (Common Annotations for the Java Plataform).

Hoje vamos ver somente a @Autowired. As outras são bem parecidas e ficam por sua conta o estudo ok?

A anotação @Autowired

A anotação @Autowired pode ser utilizada em setters, construtores ou até mesmo em uma variável de classe – independe da sua visibilidade, ou seja, mesmo que private.

Na nossa aplicação podemos utilizá-la assim:

public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	@Autowired
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	// ...
 
}

Eu, particularmente, estou mais acostumado a utilizar assim:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	private Monitor monitor;
 
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	// ...
 
}

E a última maneira seria nos setters:

public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	public Processador getProcessador() {
		return processador;
	}
 
	@Autowired
	public void setProcessador(Processador processador) {
		this.processador = processador;
	}
 
	public Monitor getMonitor() {
		return monitor;
	}
 
	@Autowired
	public void setMonitor(Monitor monitor) {
		this.monitor = monitor;
	}
 
	// ...
 
}

OBS: os getters não são uma obrigatoriedade, coloquei apenas por convenção.

Simples assim, toda vez que precisarmos das dependências elas estarão lá! Para testar podemos rodar o projeto novamente e veremos que nada mudou na saída, ou seja, tudo ainda está funcionando!

O Spring deve obrigatoriamente achar um bean para injetar no atributo anotado com @Autowired, caso contrário será lançada uma NoSuchBeanDefinitionException. Caso o atributo possa ter ou não valor, ou seja, se pode acontecer de o Spring não achar um bean para o atributo devemos setar a propriedade required da anotação para false:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired(required=false)
	private Monitor monitor;
 
	// ...
 
}

Porém quando fizer isso tome o cuidado de sempre verificar se o atributo está nulo ou não antes de utilizá-lo para evitar os famosos NullPointerException.

Outra coisa que devemos saber é que o Spring realiza uma busca por tipo (byType) para encontrar as dependências para atributos anotados com @Autowired, ou seja, como anotamos um atributo do tipo br.blog.javasimples.spring.pecas.Monitor o Spring vai procurar por algum bean que implemente essa interface para poder injetar no nosso computador.

Como disse anteriormente, caso ele não encontre nenhum bean será lançada uma NoSuchBeanDefinitionException.

Mas… – aqueles momentos em que você tem uma ideia que você acha que ninguém teve antes – e se ele encontrar mais de um bean que implemente essa interface?

Esse será o assunto do nosso próximo tópico, e só a nível de curiosidade, caso isso aconteça e não seja tratado o Spring também irá lançar uma NoSuchBeanDefinitionException.

Tratando dependências ambíguas com @Qualifier

E agora entra mais uma anotação para o nosso arsenal! hehehe

Para tratar dependências ambíguas o Spring nos oferece a anotação @Qualifier e algumas maneiras de utilizá-la. Antes de vermos todas essas maneiras vamos nos armar uma própria emboscada: criar mais um monitor para podermos simular tal erro.

/**
 * Classe que representa um monitor LED de 22 polegadas.
 * 
 * @author Felipe
 */
public class MonitorLED22 implements Monitor {
 
	private final int FREQUENCIA = 75;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[[[" + mensagem + "]]]");
	}
 
}

Nosso novo monitor é LED, muito melhor do que o antigo CRT, e tem 22”, um tamanho bem agradável. Ele é tão melhor que até o seu método de escrever coloca umas frescurinhas a mais para tentar agradar o usuário (heheheh). Vamos adicioná-lo ao arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Se tentarmos rodar agora iremos ver a nossa tão comentada NoSuchBeanDefinitionException.

Vamos ver então como podemos resolver isso de algumas maneiras diferentes.

Selecionando de acordo com o ID

Podemos especificar na anotação @Qualifier qual o ID do bean que queremos injetar:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@Qualifier("monitorLED22")
	private Monitor monitor;
 
	// ...
 
}

Ao executar nossa aplicação assim será exibida a seguinte saída indicando que nosso computador está utilizando o monitor de 22”:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [75Hz];
Computador ligado.
[[[2 + 2 = 4]]]

Selecionando de acordo com um qualificador

No exemplo anterior nós utilizamos o monitor novo, mas e se quiséssemos utilizar o antigo?

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@Qualifier("monitor")
	private Monitor monitor;
 
	// ...
 
}

Assim funciona porém não está muito intuitivo né… Um Monitor anotado com @Qualifier(“monitor”) não é muito fácil de entender né, em uma futura manutenção o pobre coitado vai ter que caçar no XML qual o bean que tem id=”monitor” para poder chegar na respectiva classe. Seria muito mais fácil se a anotação fosse @Qualifier(“monitorCRT17″) não seria?

A primeira ideia que vem na cabeça é: “beleza, vou mudar de id=”monitor” para id=”monitorCRT17″! ”.

Como nossa aplicação é apenas um exemplo bem pequeno não teria problema nenhum. Mas imagine em uma aplicação grande que já está em produção.. O risco de gerar algum erro mudando o id do bean é um pouco maior.

Para evitar isso o Spring permite que informemos um qualificador para o bean. Podemos fazer isso de duas maneiras diferentes:

No XML de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17">
		<qualifier value="monitorCRT17" />
	</bean>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Ou então na própria classe:

@Qualifier("monitorCRT17")
public class Monitor17 implements Monitor {
 
	// ...
 
}

Criando qualificadores customizados

Se você, assim como eu, acha que ficar se referindo diretamente aos IDs (ou até mesmo qualificadores) não é uma solução muito elegante o Spring permite que criemos nossos próprios qualificadores criando anotações que sejam anotadas com @Qualifier.

Vamos criar um qualificador que vai qualificar as tecnologias dos monitores, ou seja, @MonitorLED e @MonitorCRT (vou criar as anotações em um novo pacote br.blog.javasimples.spring.pecas.anotacoes):

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface MonitorCRT {
}

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface MonitorLED {
}

E vamos também anotar cada monitor com seu respectivo tipo:

@MonitorCRT
public class Monitor17 implements Monitor {
 
	// ...
 
}

@MonitorLED
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

Com isso podemos facilmente anotar a dependência do computador com a nossa nova anotação:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@MonitorLED
	private Monitor monitor;
 
	// ...
 
}

Nesse momento há aquele flash na sua cabeça (de novo) e você pergunta: “e se eu tiver 2 monitores de LED porém com tamanhos diferentes?”.

Vamos adicionar um novo monitor de LED ao nosso projeto então:

/**
 * Classe que representa um monitor LED de 19 polegadas.
 * 
 * @author Felipe
 */
@MonitorLED
public class MonitorLED19 implements Monitor {
 
	private final int FREQUENCIA = 75;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[[" + mensagem + "]]");
	}
 
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
	<bean id="monitorLED19" class="br.blog.javasimples.spring.pecas.impl.MonitorLED19"/>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Ao executar esse código caímos novamente na nossa adorável NoSuchBeanDefinitionException.

Para resolver isso podemos utilizar combinações de qualificadores, ou seja, vamos criar mais alguns qualificadores para as polegadas:

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Monitor19 {
}

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Monitor22 {
}

Vamos qualificar os monitores:

@MonitorLED
@Monitor19
public class MonitorLED19 implements Monitor {
 
	// ...
 
}

@MonitorLED
@Monitor22
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

E por fim identificar corretamente qual monitor nosso computador irá possuir:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@MonitorLED
	@Monitor19
	private Monitor monitor;
 
	// ...
 
}

Ao executar esse código recebemos a seguinte saída indicando que nosso monitor de 19 entrou em ação:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [75Hz];
Computador ligado.
[[2 + 2 = 4]]

Na minha humilde opinião essa é a melhor e mais elegante solução para resolver o problema. Podemos fazer qualquer combinação com os qualificadores desde que ela identifique somente um bean.

Descoberta automática de beans

A utilização da tag <context:annotation-config /> no arquivo de configuração do Spring possibilita a utilização de várias anotações para a injeção de dependência porém não elimina a necessidade de declarar todos os seus beans no arquivo de configuração.

Em um sistema grande ainda teremos que declarar muitos beans no XML, o que acaba sendo um pouco chato…

Para evitar isso o Spring tem uma facilidade que possibilita que ele mesmo procure pelos beans em tempo de execução, ou seja, não precisamos declará-los via XML.

Para isso precisaremos fazer uma mudança no arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:component-scan base-package="br.blog.javasimples.spring" />
 
</beans>

Agora sim temos um belo arquivo de configuração em!

A tag <context:component-scan base-package=”br.blog.javasimples.spring” /> possibilita o uso das anotações que anteriormente a tag <context:annotation-config /> possibilitava e ainda permite que o Spring procure sozinho por beans a partir do pacote br.blog.javasimples.spring (incluindo todos os subpacotes).

Porém o Spring só vai saber quais são os beans se eles estiverem identificados. Para fazer isso basta anotarmos os beans com uma das seguintes anotações:

• @Component – Uma anotação de propósitos gerais para identificar um bean;
• @Controller – Indica que o bean é um controlador do Spring Web MVC;
• @Repository – Indica que a classe é um repositório de dados;
• @Service – Indica que a classe é um serviço.

OBS: Para @Controller, @Repository e @Service existem situações em que essas anotações possuem um tratamento especial. Bateu a curiosidade? Go go Google! hehehe

Como em nossa pequena aplicação nós não precisaremos de nenhum comportamento especial podemos simplesmente anotar as nossas classes que representam beans para o container com @Component:

@Component
public class Computador {
 
	// ...
 
}

@Component
public class DualCore implements Processador {
 
	// ...
 
}

@Component
@MonitorCRT
public class Monitor17 implements Monitor {
 
	// ...
 
}

@Component
@Monitor19
@MonitorLED
public class MonitorLED19 implements Monitor {
 
	// ...
 
}

@Component
@Monitor22
@MonitorLED
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

Ao executarmos nossa aplicação agora tudo irá funcionar perfeitamente bem (ou pelo menos deveria hehehe).

É nesse momento que você tem sua última epifania do post e pergunta: “ué, lá na classe Main.java nós buscamos o computador pelo ID dele, como o Spring pegou a classe certa?”.

Muito bem observado! hehehe

Quando o Spring busca e cria automaticamente os beans ele seta o ID de cada bean com o nome da classe no padrão CamelCase para identificadores. Com isso Computador fica computador.

Mas caso haja a necessidade de especificar qual será o ID do bean basta informar na própria anotação @Component:

@Component("pc")
public class Computador {
 
	// ...
 
}

E na hora de recuperar ele basta utilizar o novo ID:

public class Main {
 
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext("br/blog/javasimples/spring/config/applicationContext.xml");
		Computador pc = (Computador) context.getBean("pc");
		pc.ligar();
		pc.somar(2, 2);
	}
 
}

Conclusão

E no fim do post temos um XML de configuração do Spring com apenas 1 linha!

Não sei quanto a vocês mas eu acho isso fantástico, onde for possível minimizar as configurações em XML é melhor pois torna o código bem mais legível e fácil de entender.

O download o projeto está disponível aqui.

Todo e qualquer feedback é muito apreciado, não custa nada escrever o que achou, é rapidinho… hehehe

[]s e até a próxima,

Saab.

É com grande prazer que venho informar que escrevi um artigo sobre Hibernate Annotations para a revista Java Magazine e o artigo foi publicado na edição número 90.

Segue um pequeno resumo do artigo:

Hibernate Annotations – Mapeamento Objeto Relacional através de Anotações

Desde que surgiu o Hibernate para ser uma ponte entre a orientação a objetos e a persistência de dados em bancos de dados relacionais, tudo o que o desenvolvedor precisa fazer é descrever suas classes com alguns metadados para poder se focar no desenvolvimento da aplicação (regras de negócio). Assim, sem se preocupar muito com a persistência de seus objetos em bancos de dados o desenvolvedor consegue aumentar sua produtividade.

Durante um bom tempo os metadados foram descritos através de XML (e são até hoje). Para cada classe que seria persistida no banco de dados era criado um novo XML explicando como o Hibernate deveria realizar o mapeamento entre atributos da classe e colunas da tabela.

Atualmente este não é mais o único modo de descrever os metadados, existe também o Hibernate Annotations, projeto que provê a descrição dos metadados através de anotações. Deste modo, ao invés de um arquivo XML para cada classe, os metadados podem ser anotados na própria classe e em seus atributos, facilitando ainda mais o processo de mapeamento.

Nesse artigo serão apresentados os conceitos necessários para entender como utilizar o framework Hibernate para persistir as classes Java em bancos de dados relacionais apenas com a descrição de metadados providos por anotações, utilizando, para isso, a IDE NetBeans 6.9.1 e o banco de dados MySQL.

Caso o assunto seja de seu interesse pode dar um pulo no site da revista ou então dar uma conferida nas bancas..

[]s,
Saab.

PS: Isso não foi marketing! Estou feliz pois meu primeiro artigo para a revista foi publicado.

Beleza, daqui pra frente vou assumir que você já sabe como linkar os beans no Spring utilizando o arquivo de configuração (pelo menos o básico, como visto na Parte 1 desta série).

Vamos ao nosso post então: AOP: Aspect Oriented Programming (POA: Programação Orientada a Aspectos). E como sempre, pra fugir um pouco dos termos técnicos, vamos a uma história:

Imagine que você está desenvolvendo um e-commerce, atualmente está desenvolvendo o checkout do teu sistema, ou seja, o cliente já escolheu tudo o que ele queria, e agora vai fazer a transferência eletrônica do pagamento (vamos imaginar que você está desenvolvendo tudo isso). Olhando com um nível de abstração muito alto o seu código poderia ser algo assim:

public class CheckoutService {
    //...
    public void efetuarPagamento(Carrinho carrinho){
        LOGGER.log(new Date().toString() + " - Executando efetuarPagamento(Carrinho carrinho)");
        if (carrinho.getCliente().temPermissao()){
             DAO.iniciarTransacao();
             try {
                 carrinho.getCliente().debitar(carrinho.getValorTotal());
                 carrinho.finalizarCompra();
                 DAO.commit();
                 LOGGER.log(new Date().toString() + " - Pagamento efetuado!");
             } catch (Exception e) {
                 DAO.rollback();
                 LOGGER.log(new Date().toString() + " - " + e.toString());
             }
        } else {
            LOGGER.log(new Date().toString() + "Cliente não está autenticado");
        }
    }
    //...
}

Dê uma boa olhada no código… O que tem a ver mesmo com o checkout são apenas as linhas:

carrinho.getCliente().debitar(carrinho.getValorTotal());
carrinho.finalizarCompra();

O resto é código responsável por logging, controle de transação, permissão de acessos, coisas que são necessárias porém que ocupam muito espaço, “sujam” o código. A idéia da orientação a objetos é encapsular em um objeto todas as coisas referentes a ele, os serviços que ele vai prestar, e não ficar poluindo ele com outros códigos que não tem nada a ver com o seu propósito.

Mas esses códigos são necessários para a aplicação funcionar corretamente! O que fazer então? Orientação a Aspectos!!!

A Orientação a Aspectos surgiu exatamente para eliminar os cross-cutting concerns (código que é necessário, porém foge das preocupações principais do objeto, como no caso acima, o checkout tem que se preocupar com o logging, transação e permissão).

OBS: Existem vários termos técnicos, sem graça, e difíceis de entender envolvidos nesse “paradigma” de programação. Nós vamos discutindo-os conforme o tutorial for andando.

Então como eu faço para separar esse código chato dos meus objetos? A Orientação a Aspectos funciona assim:

-> Primeiro a gente separa o código que não tem nada a ver com o nosso objeto (logging, transação, permissão e tals) em um lugar separado. Esse lugar separado se chama advice (é o o que).

-> Ainda dentro do advice, é definido onde o programa tem que dar uma “paradinha” para que o código que foi separado possa ser executado. Todo lugar que o programa pode dar essa “paradinha” é chamado de join point. Um join point pode ser por exemplo: uma chamada de método, a execução de um método, instanciação de objetos, execução de construtores, e mais alugns (é o quando).

-> Uma vez que nós já sabemos o que vai ser feito (advice) e quando vai ser feito (join point), falta definir onde vai ser feito. Para isso servem os pointcuts. Geralmente são definidos utilizando os nomes das classes e métodos que queremos interceptar, mas também podem ser definidos através de expressões regulares (logo mais veremos um exemplo na prática).

-> Por fim, o conjunto de tudo isso (o que vai ser feito, quando vai ser feito e onde vai ser feito) é chamado de aspect (aspecto).

Em muito poucas palavras isso é a base da orientação a aspectos. Vamos ver como a gente pode utilizar isso no Spring.

O Spring oferece diversos tipos de suporte a Orientação a Aspectos (eles foram evoluindo através das versões), dentre eles o suporte para a orientação a aspectos declarativa (no XML de configuração) e anotativa (utilizando annotations (se não sabe o que são annotations clique aqui)).

Eu estudei as duas e devo dizer que me identifiquei muito mais com a orientação a aspectos utilizando annotations, portanto é ela que eu irei mostrar aqui (caso queira aprender sobre o outro tipo eu aconselho fortemente o livro Spring in Action 2 (Manning, 2008), capítulo 4).

OBS: Eu irei reaproveitar o código da Parte 1, então caso você não tenha feito o tutorial anterior eu aconselho a pelo menos pegar os código de lá. Tudo o que eu fiz foi renomear o projeto para “OrientacaoAspectos”, o pacote principal para “orientacaoaspectos” e todas as definições dos beans no arquivo de configuração para bater com o novo nome do pacote.
Como o suporte de orientação a aspectos do Spring consegue usar a poderosa linguagem do AspectJ (para definir pointcuts) nós vamos usá-la aqui, para tanto é necessário o download da biblioteca do AspectJ e a inclusão dela no classpath. O arquivo pode ser baixado no site do projeto.
Só mais um detalhe: o arquivo que vc baixa do site eh um .jar chamado: aspectj-x.x.x.jar, dentro dele é que estão as bibliotecas que o Spring precisa, então abra este arquivo com o WinRAR (ou outro do gênero) navegue até a pasta /lib, extraia os .jar que estão lá e os adicione ao classpath.

Voltando ao escopo da nossa aplicação: o show de talentos Ídolos Spring, vamos adicionar um requisito muito importante para qualquer programa de entrenimento: a platéia!

Sem utilizar a orientação a aspectos nós teríamos os seguintes códigos:

public class Plateia {
 
    public Plateia() { }
 
    public void sentar(){
        System.out.println("A platéia está sentando");
    }
 
    public void desligarCelulares(){
        System.out.println("A platéia está desligando os celulares");
    }
 
    public void aplaudir(){
        System.out.println("CLAP CLAP CLAP UHULL CLAP CLAP");
    }
 
    public void vaiar(){
        System.out.println("UUUUUU!! E FORA! E FORA! UUUUU!! ");
    }
}

public class Cantor implements Competidor {
 
    private Musica musica;
    private Plateia plateia;
 
    public Cantor() {
    }
 
    public void setMusica(Musica musica) {
        this.musica = musica;
    }
 
    public void setPlateia(Plateia plateia) {
        this.plateia = plateia;
    }
 
    public void apresentar() {
        plateia.sentar();
        plateia.desligarCelulares();
 
        try {
            musica.cantar();
            plateia.aplaudir();
        } catch (Exception e) {
            plateia.vaiar();
        }
    }
}

OBS: A platéia estaria sendo injetada na classe Cantor pelo container assim como está acontecendo com a musica.

Sem a orientação a aspectos, toda classe que implemente a interface Competidor tem que ficar se preocupando com a platéia. Não é certo o competidor ficar mostrando os assentos para a platéia, pedir para elas desligarem os celulares, se apresentar e por fim pedir para eles aplaudirem ou vaiarem. Isso é coisa que a platéia tem que fazer sozinha!

Vamos utilizar todo o poder da orientação a aspectos para que a platéia consiga fazer isso sozinha. A classe Cantor volta a ser o que era antes, se preocupando somente em cantar a sua musica:

public class Cantor implements Competidor {
 
    private Musica musica;
 
    public Cantor() {
    }
 
    public void setMusica(Musica musica) {
        this.musica = musica;
    }
 
    public void apresentar() {
        musica.cantar();
    }
}

E a classe Plateia vai ser “anotada” para utilizar as funcionalidades da orientação a aspectos:

@Aspect
public class Plateia {
 
    public Plateia() { }
 
    @Pointcut("execution(* *.apresentar(..))")
    public void apresentacao() {}
 
    @Before("apresentacao()")
    public void sentar(){
        System.out.println("A platéia está sentando");
    }
 
    @Before("apresentacao()")
    public void desligarCelulares(){
        System.out.println("A platéia está desligando os celulares");
    }
 
    @AfterReturning("apresentacao()")
    public void aplaudir(){
        System.out.println("CLAP CLAP CLAP UHULL CLAP CLAP");
    }
 
    @AfterThrowing("apresentacao()")
    public void vaiar(){
        System.out.println("UUUUUU!! E FORA! E FORA! UUUUU!! ");
    }
}

Aconteceram algumas coisas aqui:

-> Primeiro de tudo, a classe foi anotada com a anotação @Aspect indicando o óbvio: esta classe será um aspecto;

-> Depois foi criado um método que não faz absolutamente nada chamado apresentacao() cujo único propósito deste método é ser anotado para se “tornar” um pointcut (“tornar” entre aspas porque apresentar() continua sendo um método que não faz nada, apenas contém uma anotação que é um pointcut).
O parâmetro passado para a anotação @Pointcut é uma frase na linguagem de descrição de pointcuts do AspectJ. Segue uma pequena explicação dela (que eu acabei de fazer no Paint!! hehehe):

-> Depois que o pointcut está definido, basta anotar os métodos desejados especificando quando e onde eles devem ser executados. Para especificar onde os métodos serão executados é utilizado o nome do método que está anotado com o pointcut (no nosso exemplo é a string “apresentacao()”) e para especificar quando existem algumas outras anotações. Creio que as mais utilizadas são: @Before, @AfterReturning e @AfterThrowing (caso queira saber quais são as outras, fique a vontade para fuçar na documentação).

E voilá, nosso aspecto está pronto! Para ele funcionar só falta mais uma coisinha, que não é tão pequena assim (pelo menos na teoria, na prática é sim! ).

Para a orientação a aspectos funcionar devem ser criadas cópias dos objetos que queremos interceptar. Tais cópias contém os advices (códigos das cross-cut concerns) e esse objeto é que recebe as requisições, executa os advices e depois passa a requisição para o método do objeto original. Essas cópias de objetos que contém os advices são chamados de Proxy (no plural: Proxies).

E até algumas versões atrás os proxies tinham que ser criados na mão!!! Imagine que trabalho que dava… Porém o Spring provê um mecanismo automático para a criação dos proxies (ufa!).

Segue o arquivo de configuração para podermos fazer nosso exemplo funcionar:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:aop="http://www.springframework.org/schema/aop"
        xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
            http://www.springframework.org/schema/aop
            http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
 
       <!-- competidores -->
       <bean id="atireiopau" class="orientacaoaspectos.AtireiOPauNoGato" />
       <bean id="jose" class="orientacaoaspectos.Cantor">
           <property name="musica" ref="atireiopau" />
       </bean>
 
       <bean id="ciranda" class="orientacaoaspectos.CirandaCirandinha" />
       <bean id="gaita" class="orientacaoaspectos.Gaita" />
 
       <bean id="piano" class="orientacaoaspectos.Piano" />
       <bean id="carlos" class="orientacaoaspectos.CantorTocador">
           <property name="musica" ref="atireiopau" />
           <property name="instrumento" ref="piano" />
       </bean>
 
       <!-- platéia -->
       <bean class="orientacaoaspectos.Plateia" />
       <aop:aspectj-autoproxy />
</beans>

Três coisas novas apareceram no arquivo de configuração:

1 – Na root tag () foi definido mais um namespace (xmlns:aop) e na localização dos esquemas estão os seus respectivos links. Isso é necessário para o arquivo de configuração saber quais tags podem e quais não podem quando o assunto é AOP;

2 – Foi declarado o bean correspondente à platéia. Ele não tem o atributo id definido porque provavelmente nós nunca precisaremos de uma referência à platéia, eles fazem tudo sozinhos! Não tem porque darmos um id para a platéia sendo que nunca iremos utilizá-la;

3 – A simples tag “< aop:aspectj-autoproxy />” já diz para o Spring fazer todo o trabalho duro de ficar criando os proxies para nós.

E é isso caro leitor(a) (será que mulher le isso? to brincando!! hehehe), agora é só compilar (in the java-way of course), pedir pra tia VM executar e ver a platéia trabalhando sozinha, que povo educado!

Saindo da historinha e voltando ao mundo real, é extremamente fácil prover um mecanismo de log simples e que pode sofrer modificações facilmente utilizando a programação orientada a aspectos. Suponha que sua aplicação utilize o mecanismo padrão de log do Java e queira mudar para o Log4J: simples! Basta ir no seu aspecto responsável pelo log, e alterar os códigos. Você só tem trabalho uma vez (e nem é tanto trabalho assim)!

Nos próximos posts veremos os mecanismos que o Spring provê para banco de dados, transações, segurança, e mais alguns. Tão fácil quanto um System.out.println(“Hello World”).

Quem quiser o código do projeto, está aqui.

[]s e até a próxima,
Saab.

Annotations… recurso interessante.

Sempre tive a curiosidade de saber como funcionavam, então fui perguntar pro Google.
Pretendo demonstrar aqui o que eu aprendi nas minhas pesquisas.

Annotations são… advinhem… anotações! É um jeito que você tem de fazer alguma marcação em um atributo, método, classe, entre outros.

Elas sempre devem ser digitadas antes do objeto que você queira anotar (método, atributo…) e o nome das anotações são sempre precedidos de @ (arroba). Ex:

@MinhaAnotacao
class MinhaClasse{
}

Até ai tudo bem, mas você deve estar se perguntando: “Pra que diabos eu vou usar isso? Pra que ficar enfeitando meu código?”. Calma. Tudo tem seu propósito.

Para poder trabalhar com as anotações, iremos utilizar a reflexão computacional, portanto sugiro que você leitor, leia meus posts antigos sobre Reflexão Computacional:

Java e seus Espelhos: Reflexão Computacional e

Reflexão Computacional: Exemplo Prático

Daqui pra frente vou supor que você entende e sabe utilizar a reflexão computacional…

Exemplo 1: Testando seus métodos

Então vamos lá: imagine que você é um bom programador com uma ótima noção de engenharia de software (o que realmente deve ser verdade neh… ). Você sabe que uma fase importante no desenvolvimento de um software é a fase de testes. Porém você não gosta dos frameworks existentes para teste unitário (ou qualquer outro tipo), então você decide criar o seu próprio!

Para não ficar muito chato de utilizar, você decide que durante o desenvolvimento, todo método que possuir a anotação “@Testar” será testado pelo seu framework.

OK, com essa idéia na cabeça vamos criar a nossa anotação @Testar:

Testar.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Testar { }

Reparem que a nossa anotação deve ser anotada com meta-anotações.

A anotação @Retention(RetentionPolicy.RUNTIME) diz que a VM deve manter essas anotações em tempo de execução para podermos ler elas através da reflexão. Outras opções seriam: SOURCE e CLASS.

E a anotação @Target(ElementType.METHOD) indica que a nossa anotação só é aplicada a métodos. Outras opções seriam: FIELD, TYPE (classe e interface), PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, e PACKAGE.

Reparem que para declarar a nossa própria anotação, deve-se utilizar “@interface” antes do nome da anotação.

Pronto! Só isso! É assim que as anotações são criadas. Uma vez que já temos ela, vamos criar a classe que irá ser testada.

ClasseParaTestar.java

public class ClasseParaTestar {
 
    @Testar
    public void metodo1() {
        throw new RuntimeException("Deu zebra!");
    }
 
    @Testar
    public void metodo2() {
    }
 
    @Testar
    public void metodo3() {
    }
 
    public void metodo4() {
    }
 
    @Testar
    public void metodo5() {
        throw new RuntimeException("Ixi maria... Erro!");
    }
 
    public void metodo6() {
    }
 
    @Testar
    public void metodo7() {
    }
 
    public void metodo8() {
    }
}

Como o propósito é só demonstrar as anotações, os métodos não fazem nada.

Beleza, agora os métodos que eu quero testar já estão “anotados”. Vamos criar a classe principal do nosso framework de testes.

Testador.java

public class Testador {
 
    public static void testar(Object obj) {
        Class<?> classe = obj.getClass();
        int passou = 0;
        int falhou = 0;
 
        System.out.println("-------------Inicio dos Testes--------------");
        for (Method m : classe.getDeclaredMethods()) {
            if (m.isAnnotationPresent(Testar.class)) {
                try {
                    System.out.print("Testando o método: "; + m.getName());
                    m.invoke(obj);
                    passou++;
                    System.out.println(" => passou!");
                } catch (Throwable t) {
                    falhou++;
                    System.out.println(" => falhou! " + t.getCause());
                }
            }
        }
        System.out.println("---------------Fim dos Testes---------------");
        System.out.println("Passaram: " + passou + ", Falharam: " + falhou);
    }
}

Simples simples (caso você entenda a reflexão)… Tudo o que a gente faz é verificar se o método possui a anotação @Testar, caso ele possua, o método é invocado. Se não ocorrer nenhuma exceção, então ele passou no teste, caso contrário ele falhou.

Para utilizar o nossa pequeno (micro) framework, basta chamar o método estático passando um objeto da nossa classe para testar:

Testador.testar(new ClasseParaTestar());

Para o nosso exemplo, você deve obter a seguinte saída:

-------------Inicio dos Testes--------------
Testando o método: metodo1 => falhou! java.lang.RuntimeException: Deu zebra!
Testando o método: metodo2 => passou!
Testando o método: metodo3 => passou!
Testando o método: metodo5 => falhou! java.lang.RuntimeException: Ixi maria... Erro!
Testando o método: metodo7 => passou!
---------------Fim dos Testes---------------
Passaram: 3, Falharam: 2

Obs: Eu tirei este exemplo da documentação oficial.

Exemplo 2: Validando seus atributos

Vamos criar uma classe genérica que faz a validação dos atributos de qualquer classe que você peça para ele validar. É claro que os atributos a serem validados devem possuir as anotações que nós vamos criar.

Vamos criar as nossas anotações então: @ValidarContemTexto e @ValidarPositivo.

ValidarPositivo.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface ValidarPositivo { }

ValidarContemTexto.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface ValidarContemTexto {
    int min() default 1;
}

Opa! Apareceu uma coisa nova aqui. A anotação @ValidarContemTexto possui um atributo???

É isso mesmo! As anotações podem conter atributos para realizar alguma lógica durante o processamento delas.

No nosso caso, a anotação @ValidarContemTexto irá validar se o atributo que está decorado com a anotação possui pelo menos min caracteres (que por default é 1).

Reparem que a meta-anotação @Target é ElementType.FIELD, porque vamos utilizar essas anotações para decorar atributos.

A classe Usuario para o nosso teste será a seguinte:

Usuario.java

public class Usuario {
 
    @ValidarContemTexto(min = 10)
    private String login;
 
    @ValidarContemTexto(min = 20)
    private String senha;
 
    @ValidarPositivo
    private int nivel;
 
    //Construtores, getters e setters
    //...
}

O login deverá possuir pelo menos 10 caracteres, a senha deverá possuir pelo menos 20 caracteres (para garantir alguma segurança… hehehe) e o nível deverá ser um inteiro positivo maior ou igual a zero.

Vamos ver a classe responsável pela validação:

Validador.java

public class Validador {
 
    public static boolean validar(Object obj) {
        Class<?> classe = obj.getClass();
        boolean ok = true;
 
        for (Field f : classe.getDeclaredFields()) {
            f.setAccessible(true);
 
            //Annotation @ValidarPositivo
            if (f.isAnnotationPresent(ValidarPositivo.class)) {
                try {
                    int num = Integer.parseInt(f.get(obj).toString());
                    if (num < 0) {
                        ok = false;
                        throw new Exception();
                    }
                } catch (Throwable t) {
                    System.out.println(f.getName() + " deve ser um valor inteiro positivo.");
                }
            }
 
            //Annotation @ValidarContemTexto
            if (f.isAnnotationPresent(ValidarContemTexto.class)) {
                ValidarContemTexto anotacao = f.getAnnotation(ValidarContemTexto.class);
                try {
                    String texto = f.get(obj).toString();
                    if (texto.length() < anotacao.min()) {
                        ok = false;
                        System.out.println(f.getName() + " deve possuir pelo menos " + anotacao.min() + " caracteres.");
                    }
                } catch (Throwable t) {
                    System.out.println(f.getName() + ": " + t.getCause());
                }
            }
        }
        return ok;
    }
}

Quase igual ao exemplo anterior, porém nós percorremos os atributos (getDeclaredFields()) ao invés do métodos (getDeclaredMethods()).

Um if para cada anotação… nada muito novo. A única novidade aqui é a recuperação da anotação @ValidarContemTexto para poder acessar o valor que foi definido para o seu atributo min. Mas também não é nada de outro mundo.

O código a seguir cria 3 usuários e executa a validação com cada um deles:

ArrayList<usuario> usuarios = new ArrayList<usuario>();
usuarios.add(new Usuario("login", "senha", 2));
usuarios.add(new Usuario("felipesaab", "SaabRocks", -5));
usuarios.add(new Usuario("javasimples", "javasimplesjavasimples", 0));
 
for (Usuario u : usuarios) {
    System.out.println("Validando usuario: " + u.getLogin());
    if (Validador.validar(u)) {
        System.out.println("Usuário OK.");
    } else {
        System.out.println("Corrija os erros.");
    }
    System.out.println();
}

O resultado será o seguinte:

Validando usuario: login
login deve possuir pelo menos 10 caracteres.
senha deve possuir pelo menos 20 caracteres.
Corrija os erros.
 
Validando usuario: felipesaab
senha deve possuir pelo menos 20 caracteres.
nivel deve ser um valor inteiro positivo.
Corrija os erros.
 
Validando usuario: javasimples
Usuário OK.

Chegamos ao fim de mais um post aqui do Java Simples. Espero que tenham gostado, eu pelo menos achei esse assunto interessantíssimo.

Quem quiser pode pegar os arquivos que eu fiz e testei aqui.

[]s e até a próxima,

Saab.