public class MinhaClasse {
 
    private static MinhaClasse instance;
 
    public static MinhaClasse getInstance() {
 
    	if (instance == null) {
    		instance = new MinhaClasse();
    	}
 
        return instance;
    }
 
    // outras coisas
}

Esse é um jeito de fazer cache. Apenas deve-se tomar cuidado para que o objeto a ser retornado não seja mutável. Afinal, todos os interessados estão com a mesma instância, e se um dos clientes puderem mudar uma propriedade desse único objeto, todos terão o efeito indesejável de ter um objeto com comportamento diferente sem saber. Detalhe: a implementação de singleton dessa maneira é ingênua, evite-a.

Um outro jeito, comumente usado, de fazer cache é usar session. Pra quem tem uma aplicação web, parece mágico: joga-se uma entidade da persistência na sessão passando uma chave. Ao precisar do mesmo objeto de novo, ao invés de acessar o banco, pega-se o objeto da sessão com a mesma chave usada na escrita. Esse é a estratégia mais comum que eu já vi por aí. Mas existem vários problemas : já vi aplicações com mais código pra cache em sessão do que pro próprio negócio! Além do mais, sessions são únicas para cada usuário no browser, enquanto que a entidade a ser cacheada é, não raro, visível a vários usuários. Significa duas coisas: 1) Não vai ter uma cacheamento efetivo, se 20 usuários se logarem e todos acessarem a mesma entidade duas vezes, haverá vinte cópias do objeto, que será escrita e lida uma vez cada; 2) Ninguém sabe o que um outro usuário pode fazer, se um alterar a entidade, todos os dezenove usuários restantes não terão como saber disso e manterão cópias desatualizadas. Session não foi feita pra cache, e existe até um problema de design: apesar do mapa de sessão pertencer à camada de apresentação, o cache lida com problemas de objetos que surgem na camada de persistência. Dizer que um pode ser usado para implementação do outro resulta em confusões de conceitos.

Uma solução melhor é usar bibliotecas de cache. No Java, um bastante comum é o EHCache — usado principalmente para o cache de segundo nível de Hibernate — que fica na mesma JVM da sua aplicação. Não que seja ruim (tem até uns javeiros roxos que acham que esta é a melhor solução do mundo), mas quando se quer usar um cluster de aplicações web, por exemplo, passa-se a ter vários caches para cada instância de servidor, que é não o desejável. Uma das opções de cache, que fica fora da JVM de sua aplicação, é o Memcached.

A seguir, apresentarei as vantagens do Memcached, seu mecanismo básico junto com uma API do Java, e no final, o uso integrado com o Hibernate.

Características do Memcached

Memcached permite a chamada escalabilidade horizontal, ou seja, é possível usar várias instâncias de memcached em paralelo como se fosse uma única unidade, onde cada processo possui somente parte dos registros. Parece idiota, mas não é. Não é toda infraestrutura que lhe permite isso; bancos de dados tradicionais, sistemas operacionais e máquinas virtuais possuem uma dificuldade tremenda de configurações para que isso seja possível.

Porém, ser fácil de se escalar horizontalmente trouxe certos custos na sua implementação. Exemplo: Não existe replicação de dados automática, se quiser duas instâncias com dados iguais, terá que fazer seu script. Não existe transação e nem lock, pois isso gera contenção. Não existem busca por todos os registros ou por wildcards, pois pode causar demora nos resultados. E não há garantia de durabilidade de objetos armazenados em casos de crash.

E ainda duas características peculiares, uma é que o tempo de expiração no cache não é zerado com consultas (como é tradicional nas sessions de containeres web), ou seja, se você definir como tempo de expiração dois minutos, esse será o tempo que ficará armazenado, independente se houve consulta do registro nesse meio-tempo ou não. Portanto, sempre coloque no memcached objetos que já estejam persistidos em outro lugar. A segunda característica é que o tempo de expiração é definido por segundos que devem ser armazenados, ou seja, uma hora é 3600. Mas apenas se o tempo de permanência for menor que trinta dias, se for maior, o Memcached assume que é o tempo UNIX absoluto, ou seja, 1240699927 significa que o registro deve permanecer em cache até em 25 de abril de 2009 às 22h52min07 em UTC.

Como usar

Se você estiver usando alguma distribuição Linux, com certeza o Memcached pode ser baixado diretamente de seu repositório. Caso você seja um usuário Windows, existem portes do cache para esse Sistema Operacional aqui e aqui. Como só tenho o Fedora, não testei pra ver se funciona, então o Google será melhor pra resolver problemas de instalação no Windows do que eu.

Além disso, é necessário um cliente Memcached, que existem para várias linguagens. No Java, a melhor biblioteca que encontrei é a Spy Memcached, disponível na versão 2.3.1. Baixe o arquivo e coloque no classpath de sua aplicação.

Incialize o Memcached no seu shell dessa maneira:

memcached -p 18000 -vv

A opção -p indica a porta da conexão TCP por onde será “ouvida” (não é necessário, se não informar será assumido o padrão 11211), e o -vv é a opção verbose.

Na sua aplicação Java, você abre um cliente Memcached dessa maneira:

MemcachedClient mem = new MemcachedClient(new InetSocketAddress("localhost", 18000));

Ou seja, passando um endereço de rede ao construtor do MemcachedClient. Caso você queira um cluster de aplicações Memcached, é possível também passar uma lista de endereços de redes, assim:

MemcachedClient mem = new MemcachedClient(new InetSocketAddress[] {
				new InetSocketAddress("localhost", 18000),
				new InetSocketAddress("localhost", 18001),
			});

Obviamente, é necessário duas instâncias de Memcached disponíveis nesses endereços.

As operações que o Memcached suporta são simples, exemplos:

set

A operação set insere um valor para uma dada chave, independente se esta já possuía um valor anterior ou não:

     String marca = "Ford";
     int expira = (int) (System.currentTimeMillis() + 60 * 60 * 1000) / 1000; // uma hora pra expirar
 
     Future<Boolean> valido = mem.set("marca", expira, marca);

Lembre-se também do comportamento dos trinta dias, as duas formas abaixo setam o mesmo período de expiração:

     Future<Boolean> valido = mem.set("marca", 24 * 60 * 60, marca); // um dia para expirar
     Future<Boolean> valido = mem.set("marca", (int) (System.currentTimeMillis() + 24 * 60 * 60 * 1000) / 1000, marca); // também um dia

É possível setar qualquer coisa, inclusive objetos Java que sejam seriálizáveis. Porém, qualquer coisa diferente de um tipo simples não é identificável para programas em outras linguagens que se conectarem a esse mesmo Memcached.

add

A operação add, apesar do nome, insere um valor para uma dada chave, deste que esta não esteja com um elemento previamente armazenado:

     Pessoa pessoa1 = new Pessoa();
     pessoa1.setId(28L);
     pessoa1.setName("Leonardo");
 
     Future<Boolean> valido1 = mem.add("pessoa", 60 * 60, pessoa1); // valido1 é true
 
     Pessoa pessoa2 = new Pessoa();
     pessoa2.setId(41L);
     pessoa2.setName("Vinicius");
 
     Future<Boolean> valido2 = mem.add("pessoa", 60 * 60, pessoa2); // valido2 é false

replace

A operação replace, ao contrário do add, insere um valor para uma dada chave apenas se esta já estiver anteriormente armazenado:

     int anoLancamento = 2010;
     Future<Boolean> valido1 = mem.replace("anoLancamento", 60 * 60, anoLancamento); // valido1 é false
 
     Future<Boolean> ok = mem.set("anoLancamento", 60 * 60, anoLancamento); // set armazena de qualquer jeito
     ok.get(); // bloqueia até a conclusão
 
     int novoAnoLancamento = 2011;
     Future<Boolean> valido2 = mem.replace("anoLancamento", 60 * 60, novoAnoLancamento); // valido2 é true

get

A operação get busca um registro armazenado anteriormete, dada uma chave:

     String marca = (String) mem.get("marca"); // "Ford", ou null se demorou demais ou expirou

delete

A operação delete apaga um valor no Memcached dada a chave. O valor armazenado não é retornado:

     Future<Boolean> valido1 = mem.delete("anoLancamento"); // true
 
     Future<Boolean> valido2 = mem.delete("anoLancamento"); // false

incr

A operação incr incrementa um valor previamente armazenado. Válido somente para números:

     long valor1 = mem.incr("contador", 9, 5); /* o segundo parâmetro é valor a ser incrementado */
                                               /* o terceiro parâmetro (opcional) é o valor inicial caso não haja nenhum par armazenado */
                                               /* valor1 = 5 */
 
     long valor2 = mem.incr("contador", 7); /* se não informasse o valor inicial e esta fosse a primeira chamada, o retorno seria -1 */
                                            /* valor2 = 12 */

decr

A operação decr decrementa um valor previamente armazenado. Válido somente para números:

     long valor1 = mem.decr("contador", 12, 20); /* valor1 = 20 */
     long valor2 = mem.decr("contador", 9);      /* valor2 = 11 */

Lembre-se: os números são só positivos. Se o valor armazenado é 4 e você decrementar 6, o valor final é 0 (zero).

Exemplo de cache para banco de dados

Vamos a uma situação prática. Imagine um banco de consulta de preços de um supermercado. Alguns preços são consultados com bastante frequência e seus preços são raramente alterados. Idealmente, seria interessante cachear esses valores retornados para aliviar a carga do banco. Meu objeto de domínio é um só:

public class ProductDescription implements Serializable {
 
	private long barCode;
 
	private String description;
 
	private BigDecimal price;
 
	private String type;
 
	// getters e setters omitidos
}

Meu acesso aos dados obedece a essa interface:

package br.com.objectzilla.testeDaoMemcached;
 
public interface ProductDescriptionRepository {
 
	ProductDescription getByBarCode(long barCode);
 
	void refreshProductInformation(ProductDescription product);
}

Ou seja, existe um método para retornar um pedido por código de barras (getByBarCode()) e outro que atualiza ou insere um produto (refreshProductInformation()).Também tenho uma classe, implementando essa interface, que executa comandos SQL no banco via JDBC (ProductDescriptionDAO, não mostrado).

O pulo do gato é uma classe, que fica como um Decorator, que realiza o cache, veja:

package br.com.objectzilla.testeDaoMemcached;
 
import net.spy.memcached.MemcachedClient;
 
public class ProductDescriptionCacheDecorator implements ProductDescriptionRepository {
 
	private MemcachedClient memcachedClient;
	private int expiration;
	private ProductDescriptionRepository other;
 
	public ProductDescription getByBarCode(long barCode) {
 
		ProductDescription product = (ProductDescription) memcachedClient.get("product_descr/" + barCode);
		if (product == null) {
			product = other.getByBarCode(barCode);
 
			memcachedClient.add("product_descr/" + barCode, expiration, product);
		}
		return product;
	}
 
	public void refreshProductInformation(ProductDescription product) {
		other.refreshProductInformation(product);
 
		memcachedClient.delete("product_descr/" + product.getBarCode());
	}
 
	public void setMemcachedClient(MemcachedClient memcachedClient) {
		this.memcachedClient = memcachedClient;
	}
 
	public void setExpiration(int expiration) {
		this.expiration = expiration;
	}
 
	public void setOther(ProductDescriptionRepository other) {
		this.other = other;
	}
}

Primeiro, a variável other refere-se a uma outra classe que implementa também ProductDescriptionRepository, como a classe acima é um decorator, natural que essa referência seja de um objeto que realmente faz acesso ao banco. Tem-se também a instância de um MemcachedClient e a instância de um período de expiração, para ser usado para a manipulação de dados do Memcached.

Veja, primeiro, o método getByBarCode, a primeira coisa que se faz é buscar um registro no memcached usando uma chave formada do nome abreviado do objeto seguido do código de barras do produto (o id). Havendo esse registro, retorna-o, e aí a consulta ao banco não é realizada e fim de papo. Se esse registro não estiver no Memcached, aí este é buscado no banco (através de other) e, em sequência, realizada a inserção do objeto no cache, para que as próximas chamadas desse método não façam busca no banco de novo. Lembre-se que o cache expira, e não é apropriado assumir que o objeto está sempre no cache, portanto é sempre necessário ter essa verificação de registro vazio em todas as suas consultas.

Ao inserir ou alterar um registro, o dado no cache fica desatualizado. Por isso, existe uma chamada para remover o ítem após a inserção bem sucedida no método refreshProductInformation(). Poderia haver uma inserção no memcache nesse ponto, mas preferi não fazer, porque de qualquer forma, isso será feito no método de busca.

A aplicação que exercita esse cache está disponível nesse zip, caso queiram estudá-lo com mais detalhes.

Usando como cache de segundo nível do Hibernate

O Hibernate possui suporte a cache de segundo nível, e a implementação mais comum é o EHCache, que vem junto com o framework de persistência. Por ter um cache quase automático (pois você precisa habilitá-lo para cada entidade mapeada), é meio desvantajoso fazer cacheamento manualmente como fiz anteriormente. Incrivelmente, na minha busca por Memcached no Google, me deparei com o plugin hibernate-memcached que usa o Memcached como cache de segundo nível.

Se a opção for essa, as coisas facilitam bastante. Primeiro, anotaremos a entidade ProductDescription, assim:

@Entity
@Table(name="product_description")
@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class ProductDescription implements Serializable {
 
	@Id
	@Column(name="bar_code")
	private long barCode;
 
	private String description;
 
	private BigDecimal price;
 
	private String type;
 
	// getters e setters
}

Existem as anotações triviais do JPA, como @Entity, @Table, @Id e @Column. Mas existe também a anotação específica do Hibernate, que é o @Cache. Na estratégia de concorrência, estou dizendo que é possível haver escrita e leitura, mas que a escrita não bloqueia leituras. Sem esta anotação, o cache não funciona pra essa entidade. (Por isso, se você um dia colocou o cache de segundo nível que você queria nas configurações, mas nunca colocou a anotação @Cache nas entidades, é a mesma coisa que não ter cache de segundo nível.)

O Dao faz acessos ao Hibernate normalmente (estou usando o template do Spring):

package br.com.objectzilla.hibernateMemcached;
 
import org.hibernate.SessionFactory;
import org.springframework.orm.hibernate3.HibernateTemplate;
import org.springframework.transaction.annotation.Transactional;
 
@Transactional
public class ProductDescriptionDAO implements ProductDescriptionRepository {
 
	private HibernateTemplate hibernateTemplate;
 
	public ProductDescription getByBarCode(long barCode) {
		return (ProductDescription) hibernateTemplate.get(ProductDescription.class, barCode);
	}
 
	public void refreshProductInformation(ProductDescription product) {
		product = (ProductDescription) hibernateTemplate.merge(product);
		hibernateTemplate.saveOrUpdate(product);
	}
 
	public void setSessionFactory(SessionFactory sessionFactory) {
		hibernateTemplate = new HibernateTemplate(sessionFactory);
	}
}

E pra configurar, basta adicionar essas propriedades no hibernate.cfg.xml:

<property name="hibernate.cache.provider_class">com.googlecode.hibernate.memcached.MemcachedCacheProvider</property>
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.memcached.servers">localhost:14001</property>

Onde eu indico o provedor do cache, a opção de se fazer cache de queries, e o servidor do Memcached. Não são as únicas opções, mas as outras possuem opção default, que você encontra aqui.

É só isso, agora é só adiconar o hibernate-memcached e o spy-memcached no seu classpath e rodar a aplicação. Também disponibilizei um zip para esse exemplo, caso vocês queiram dar uma olhada.

Conclusão

Usar cache, seja o Memcached ou qualquer outro, é uma boa opção para evitar acesso a recursos custosos, como o banco de dados. Mas, numa aplicação dividida em camadas não é sempre necessário que a responsabilidade de cachear fique no lado cliente (camada de apresentação). Se deixar que o lado servidor (camada de persistência) tenha essa responsabilidade, você pode deixar que os clientes acessem a camada de persistência na hora e do jeito que bem entenderem e, ainda assim, de maneira transparente, estará sendo feito acesso eficiente de recursos.

Eu havia feito uma medição bem informal de quanto o Memcached economizaria o tempo de busca. Levei à conclusão de que por causa de warm-up e tudo mais, eu não sei fazer benchmarks. O mais importante do cache não costuma nem ser o tempo de acesso mais rápido, mas o fato de não deixar “engargalar” o banco com muitos acessos.

Primeiro, feche o Eclipse. Iremos copiar o plugin do Glassfish e descompactá-lo, para alterar o seu arquivo de configurações. No Linux eu fiz assim, supondo que ECLIPSE_HOME seja uma variável onde aponta para a pasta do Eclipse:

$ mkdir -p ~/plugin # cria pasta plugin dentro de seuhome
 
$ cd $ECLIPSE_HOME/plugins #entra na pasta plugins dentro de eclipse
 
$ cp com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar ~/plugin/ # copia o plugin do Glassfish para sua pasta
 
$ cd ~/plugin/ # vá para a sua pasta...
 
$ unzip com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar -d plugin_glassfish # e extrai o conteúdo do jar dentro da subpasta plugin_glassfish
 
$ cd plugin_glassfish/serverdef/ #entre na pasta serverdef (do conteúdo recém extraído)
 
$ vim glassfishv3preludeserverdef.xml # edite este arquivo (não precisa ser, necessariamente, o vim)

Você vai encontrar isso na linha 184:

<archive path="${sunappserver.rootdirectory}/modules/web/jsf-impl.jar" />
<archive path="${sunappserver.rootdirectory}/modules/web/jstl-impl.jar" />

Troque para:

<archive path="${sunappserver.rootdirectory}/modules/jsf-impl.jar" />
<archive path="${sunappserver.rootdirectory}/modules/jstl-impl.jar" />

Agora vamos reempacotar o jar e devolvê-lo pro Eclipse:

$ cd ~/plugin # volta onde está a cópia do plugin do Eclipse
 
$ mv com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar__old # mude o nome
 
$ cd plugin_glassfish/ # entre na pasta com conteúdo "dezipado"
 
$ zip -r ../com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar ./ # e faça o zip de novo com o mesmo nome do jar
 
$ cd .. # volte um nível
 
$ cp com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar $ECLIPSE_HOME/plugins/ # e copie o novo jar para a pasta de plugins do Eclipse

Ao abrir o Eclipse de novo, na versão b37, o projeto não sentirá mais falta de bibliotecas. Voltando…

No post anterior, fizemos uma aplicação já utilizando os recursos do EJB Lite. Porém, faltava alguma coisa para persistir os objetos.

No teste, instanciava-se ali mesmo os objetos necessários e jogava-os no método marcaConsulta(). Porém, num caso real, os objetos precisariam existir muito antes, armazenados num meio persistente (na maioria das vezes, em um banco de dados relacional). A prática corrente é encapsular essa obtenção de objetos do meio persistente através do DAO (Data Access Object, ou objeto de acesso aos dados). Nessa aplicação, seguiremos a prática de separar a interface da implementação, e chamarei a interface de .*Repository e a classe que a implementa de .*DAO. Usarei EJB Lite também para a implementação de persistência.

Aquele primeiro teste será modificado para buscar os objetos do repositório. Estaremos utilizando o JMock para simular o DAO, pois, além de não termos uma fonte de dados real (por enquanto), testes que dependem de recursos externos perdem a confiabilidade. Melhor fazer um stub e ter certeza que traz o resultado esperado

package br.com.objectzilla.agendamedica;
 
import java.util.Calendar;
 
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.junit.Assert;
import org.junit.Test;
 
public class AgendamentoTeste {
 
	@Test
	public void pacienteMarcaHoraComMedico() {
 
		Mockery context = new JUnit4Mockery();
 
		// ajustando o repositório de paciente
		final PacienteRepositorio pacienteRep =  context.mock(PacienteRepositorio.class);
 
		context.checking(new Expectations() {{
			Paciente paciente = new Paciente();
			paciente.setNome("Maria");
 
			oneOf (pacienteRep).getPaciente(32L); will(returnValue(paciente));
		}});
 
		// ajustando o repositório de médico
		final MedicoRepositorio medicoRep = context.mock(MedicoRepositorio.class);
 
		context.checking(new Expectations() {{
			Medico medico = new Medico();
			medico.setNome("Dr. Gregory House");
 
			oneOf (medicoRep).getMedico(4L); will(returnValue(medico));
		}});
 
		// um paciente...
		Paciente paciente = pacienteRep.getPaciente(32L);
 
		// um médico...
		Medico medico = medicoRep.getMedico(4L);
 
		// ambos agendam um horário
		Agendamento agendamento = new AgendamentoImpl();
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medico, paciente, horario);
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medico.consulta(horario);
		Assert.assertEquals(paciente.getNome(), pacienteMarcado.getNome());
	}
}

Tanto MedicoRepositorio quanto PacienteRepositorio são interfaces (mais tarde, criarei as implementações). Ao criá-las, o teste já é executado com sucesso.

Agora chegou a hora de refatorar. Repare que o teste, do jeito que está, é imbecil. Os mocks apenas complicaram a obtenção de objetos e, se deixasse como antes, seria a mesma coisa! Mas eu fiz essa alteração para um próximo passo: os repositórios não serão mais chamados pelo meu teste, mas pelo método marcaConsulta(), que receberia apenas os ids de médico e paciente. E como consequência, os mocks servirão para indicar que os métodos dos repositórios realmente são chamados. Veja como fica:

		// ajustando o repositório de paciente (omitido, pois é como era antes)
		// ajustando o repositório de médico (omitido, pois é como era antes)
 
		// id de paciente e médico
		long pacienteId = 32L;
		long medicoId = 4L;
 
		// cria um agendamento, passando os repositórios como parâmetro
		Agendamento agendamento;
		{
			AgendamentoImpl impl = new AgendamentoImpl();
			impl.setPacienteRepositorio(pacienteRep);
			impl.setMedicoRepositorio(medicoRep);
			agendamento = impl;
		}
 
		// cria um horário para a consulta
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medicoId, pacienteId, horario);
 
		// verifica se os métodos definidos no mock foram realmente chamados
		context.assertIsSatisfied();
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medicoRetornado.consulta(horario);
		Assert.assertEquals(pacienteRetornado.getNome(), pacienteMarcado.getNome());

Tente executar até que fique com sucesso. Se quiser, dentro do método marcaConsulta(), ao invés de pegar os objetos dentro dos repositórios, crie novos objetos Medico e Paciente. Vai dar erro, porque foi adicionado no teste a instrução context.assertIsSatisfied(), que garante que os métodos definidos no mock sejam realmente chamados por apenas uma vez (e dê erro caso contrário).

Existe ainda mais uma oportunidade de teste: o que acontece quando eu uso um identificador para um objeto que não existe? Deveria lançar exceção, mas, atualmente, a assinatura do método dos repositórios não possui qualquer sinalização disso. Farei também um teste para o caso de não achar objetos. Mas nesse caso, não mostrarei aqui, estando apenas no meu GitHub.

Chegou a hora da verdade, como fazer os façades existentes se tornarem Session Beans? Simples, com anotações! Primeiro, as interfaces de repositório:

@Local
public interface MedicoRepositorio {
 
	Medico getMedico(long id) throws MedicoNaoEncontradoException;
}

@Local
public interface PacienteRepositorio {
 
	Paciente getPaciente(long id) throws PacienteNaoEncontradoException;
}

A implementação do Session Bean Agendamento possui agora as dependências com os repositórios:

@Stateless
public class AgendamentoImpl implements Agendamento {
 
	@Override
	public void marcaConsulta(long medicoId, long pacienteId, Calendar horario)
			throws PacienteNaoEncontradoException, MedicoNaoEncontradoException {
		Paciente paciente = pacienteRepositorio.getPaciente(pacienteId);
		Medico medico = medicoRepositorio.getMedico(medicoId);
 
		medico.consulta(paciente, horario);
 
		medicoRepositorio.salvaConsultaMedico(medico);
	}
 
	@EJB
	public void setPacienteRepositorio(PacienteRepositorio pacienteRep) {
		pacienteRepositorio = pacienteRep;
 
	}
 
	@EJB
	public void setMedicoRepositorio(MedicoRepositorio medicoRep) {
		medicoRepositorio = medicoRep;
	}
 
	private PacienteRepositorio pacienteRepositorio;
	private MedicoRepositorio medicoRepositorio;
}

Na implementação dos repositórios, ainda não colocarei a persistência com o banco de dados. Ao invés disso, deixarei os objetos em memória. Numa situação como essa, esse lugar da memória deveria ser o único em toda a aplicação, ou seja, singleton. Até agora, singletons deveriam ser feitos à mão; na próxima versão, será possível usar EJB, bastando uma anotação, veja:

@Singleton
public class MedicoDAO implements MedicoRepositorio {
  //...
}

Isso é ainda uma demonstração, quando eu usar um banco de dados de verdade, voltarei a usar @Stateless. De fato, não é porque existe @Singleton que você sempre deve usá-lo porque, com essa anotação, as chamadas aos métodos serão serializadas (não ocorre execução em paralelo), reduzindo sensivelmente a escalabilidade. Portanto, use como último recurso. O código completo do DAO, você vê no meu GitHub.

Acabou? Nããããããooo! Vamos imaginar como seria uma tela de agendamento:
- Mostra-se uma lista de médicos, uma lista de pacientes e pede-se um horário de consulta.
- O usuário marca a consulta.
- Mostra-se a consulta marcada.

Três coisas que falta nos DAOs, uma busca por lista de médicos, outra para lista de pacientes, e um método que salva a consulta. Farei os três métodos:

@Local
public interface PacienteRepositorio {
 
	Paciente getPaciente(long id) throws PacienteNaoEncontradoException;
 
	List<Paciente> todosPacientes();
}

@Local
public interface MedicoRepositorio {
 
	Medico getMedico(long id) throws MedicoNaoEncontradoException;
 
	List<Medico> todosMedicos();
 
	void salvaConsultaMedico(Medico medico);
}

No teste, adicionarei também a exigência do método de marcarConsulta() salvar a consulta do médico. Mas, pra variar, não vou mostrar. (Se você estiver atento, faltou o conceito de Consulta, que está escondido como um atributo do médico. Numa próxima oportunidade, antes de adicionar qualquer outra funcionalidade, criarei esse tipo.)

Vamos às páginas web! Usarei Servlets e JSPs. A primeira página pega todos os pacientes e todos os médicos e exibe uma tela para digitar o horário da consulta. Seguindo o MVC, temos o Servlet agindo como Controller:

@WebServlet(value="/agendaForm")
public class AgendaFormServlet extends HttpServlet {
 
	private static final long serialVersionUID = -7874706688461756994L;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		// obtém médicos
		List<Medico> medicos = medicoRepositorio.todosMedicos();
		req.setAttribute("medicos", medicos);
 
		// obtém pacientes
		List<Paciente> pacientes = pacienteRepositorio.todosPacientes();
		req.setAttribute("pacientes", pacientes);
 
		// passa para uma página jsp
		req.getRequestDispatcher("/WEB-INF/agendaForm.jsp").forward(req, resp);
	}
 
	@EJB
	private MedicoRepositorio medicoRepositorio;
 
	@EJB
	private PacienteRepositorio pacienteRepositorio;
}

Não se deveria haver duas chamadas ao model dentro de um controller. Mas nesse caso, não consigo imaginar uma situação melhor. Acho muito burocrático fazer um método que retorna um DTO contendo as listas de Medico e Paciente; além do nome do método resultante não ter uma boa abstração (ou você acha que listaMedicoEPaciente() é um nome bom?). E não consigo achar um jeito de usar apenas um objeto raiz, onde os outros seriam obtidos através deste; a relação entre Medico e Paciente ainda vai ser criada, ela não existe no momento de carregar o formulário. Portanto, deixarei assim mesmo.

A view não possui nada de novo em relação às versões anteriores:

	<jsp:useBean id="medicos" scope="request" type="java.util.List"/>
	<jsp:useBean id="pacientes" scope="request" type="java.util.List"/>
 
	<form method="POST" action="marcaConsulta">
		<p>Selecione o m&eacute;dico:
		<select size="1" name="medicoId">
			<option value="0">M&eacute;dicos</option>
			<c:forEach items="${medicos}" var="medico">
			<option value="${medico.id}">${medico.nome}</option>
			</c:forEach>
		</select>
		</p>
		<p>Selecione o paciente:
		<select size="1" name="pacienteId">
			<option value="0">Pacientes</option>
			<c:forEach items="${pacientes}" var="paciente">
			<option value="${paciente.id}">${paciente.nome}</option>
			</c:forEach>
		</select>
		</p>
		Dia: <input type="text" name="dia" size="10"><br/>
		Hora: <input type="text" name="hora" size="10"><br/>
 
		<p><input type="submit" value="Marcar Consulta"></p>
	</form>

O conteúdo será enviado à ação marcaConsulta, que será feita através da alteração do antigo Servlet AgendamentoServlet:

package br.com.objectzilla.agendamedica;
 
import java.io.IOException;
import java.io.PrintWriter;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;
 
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet(value = "/marcaConsulta")
public class AgendamentoServlet extends HttpServlet {
 
	private static final long serialVersionUID = -1218896541620785877L;
 
	@EJB
	private Agendamento agendamento;
 
	@Override
	public void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		try {
			long medicoId = Long.parseLong(req.getParameter("medicoId"));
			long pacienteId = Long.parseLong(req.getParameter("pacienteId"));
 
			DateFormat dateFormat = DateFormat.getDateTimeInstance(DateFormat.SHORT,
					DateFormat.SHORT, req.getLocale());
 
			String horario = req.getParameter("dia") + " " + req.getParameter("hora");
			Date date = dateFormat.parse(horario);
 
			Calendar cal = Calendar.getInstance(req.getLocale());
			cal.setTime(date);
 
			// chamando método de agendamento
			agendamento.marcaConsulta(medicoId, pacienteId, cal);
 
			resp.sendRedirect(resp.encodeRedirectURL("consulta?medicoId=" + medicoId
					+ "&horario=" + horario));
 
		} catch (Exception e) {
			PrintWriter out = resp.getWriter();
			out.print("Você fez alguma coisa de errado!");
		}
	}
}

Dessa vez, apaguei o doGet() e coloquei a ação de salvar a consulta em um doPost(). Realizei um redirect em um outro Servlet que faz a consulta de horários.

Servlet:

package br.com.objectzilla.agendamedica;
 
import java.io.IOException;
import java.io.PrintWriter;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;
 
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet(value="/consulta")
public class ConsultaServlet extends HttpServlet {
 
	private static final long serialVersionUID = 8084899967543431263L;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		try {
			long medicoId = Long.parseLong(req.getParameter("medicoId"));
 
			Medico medico = medicoRep.getMedico(medicoId);
 
			DateFormat df = DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT, req.getLocale());
			Date d = df.parse(req.getParameter("horario"));
 
			Calendar horario = Calendar.getInstance(req.getLocale());
			horario.setTime(d);
			req.setAttribute("horario", horario);
 
			Paciente paciente = medico.consulta(horario);
 
			if (paciente == null) {
				paciente = new Paciente();
				paciente.setNome("(ninguém)");
			}
 
			req.setAttribute("paciente", paciente);
 
			req.getRequestDispatcher("/WEB-INF/consulta.jsp").forward(req, resp);
 
		} catch (Exception e) {
			PrintWriter out = resp.getWriter();
			out.println("Você fez alguma coisa de errado!<br/><br/>");
			e.printStackTrace(out);
		}
	}
 
	@EJB
	private MedicoRepositorio medicoRep;
}

E JSP:

	<jsp:useBean id="paciente" scope="request" type="br.com.objectzilla.agendamedica.Paciente"/>
	<jsp:useBean id="horario" scope="request" type="java.util.Calendar"/>
 
	<p>Data: <fmt:formatDate value="${horario.time}" type="both" dateStyle="long" timeStyle="medium"/></p>
 
	<p>Paciente: ${paciente.nome}</p>
 
	<a href="agendaForm">De novo</a>

Você pode agora digitar http://localhost:8080/AgendaMedica/agendaForm no seu browser e inserir uma consulta qualquer. Ao fazer a submissão, uma nova página será exibida, cuja URL tem parâmetros de medicoId e horario. Mude esses parâmetros e você verá que, em horários que você não marcou horário, aparece (ninguém) como paciente.

Faltam coisas ainda. A agenda permite horários esdrúxulos, como agendamento no passado, agendamento fora do horário comercial, agendamento de dois pacientes com um minuto de intervalo, e sobreposição de horário. Precisamos resolver todas essas validações. E outra, precisamos criar a classe Consulta, pois não faz sentido temos que mudar Médico quando um paciente quer marcar um dia. E seria bem melhor também, fazer as páginas web com algum framework. JSF 2.0 seria uma ótima pedida.

Mas tudo isso num próximo post.

E você também pode fazer isso. Pegue uma versão promoted do Glassfish no site deles, que, assim como o Lost, tem sempre uma versão nova nas quartas à noite, que você baixa na quinta. A última versão, que estou usando nesta semana, é a b36.

Baixe a última versão disponível e descompacte num lugar que você achar apropriado. No Eclipse, na hora de instalar o servidor, basta escolher a opção “Glassfish v3 Prelude” (se você não usava Glassfish, na tela de novo servidor há uma opção de baixar os adaptadores para outros servidores). Pronto!

Eu vou fazer uma aplicação de exemplo, que é uma agenda de consultório médico. É babaca, mas tem uma regras óbvias que não dá pra ser tratado com o velho CRUD.

Vamos lá. Crie um “Dynamic Web Project” cujo Runtime seja o “Glassfish v3 Prelude”, vou chamá-lo de AgendaMedica. Não sei como vocês lidam com testes no Eclipse, mas costumo criar um novo projeto Java que referencia o projeto que estou interessado em testar. No caso, criarei também o projeto Java AgendaMedicaTeste. Após criado, dê <Alt> + <Enter> sobre o projeto, clique em “Java Build Path”, vá na aba “Projects” e adicione o projeto AgendaMedica.

No projeto AgendaMedicaTeste, eu já criei um método de testes pra realizar a consulta:

package br.com.objectzilla.agendamedica;
 
import java.util.Calendar;
 
import org.junit.Assert;
import org.junit.Test;
 
public class AgendamentoTeste {
 
	@Test
	public void pacienteMarcaHoraComMedico() {
		// um paciente...
		Paciente paciente = new Paciente();
		paciente.setNome("Maria");
 
		// um médico...
		Medico medico = new Medico();
		medico.setNome("Dr. Gregory House");
 
		// ambos agendam um horário
		Agendamento agendamento = new AgendamentoImpl();
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medico, paciente, horario);
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medico.consulta(horario);
		Assert.assertEquals(paciente.getNome(), pacienteMarcado.getNome());
	}
}

Beleza, mas o código não compila, né? Ora, não seja por isso. Vá criando as classes clicando nos erros com o botão direito do mouse, só não se esqueça de colocar as classes no projeto AgendaMedica. No caso, Agendamento é uma interface e o restante são classes.

Bom, tente rodar o script de teste (clique com botão direito sobre a classe e dê Run As… > JUnit Test). Vai dar erro, óbvio! Por isso, convido a você a escrever código nas classes até o script rodar com sucesso. Não se preocupe, se você não conseguir ou não tiver paciência, no final do post eu mostro o link onde você pode baixar o código.

Agora, vamos transformar a interface Agendamento em um Stateless Session Bean. Não precisa nem mover pra um projeto próprio, pois agora os EJBs podem ser “deployados” em aplicações WAR. Basta adicionar @Local na interface (a v3 ainda não possui suporte a @Remote), assim:

@Local
public interface Agendamento {
	// ...
}

E adicionar @Stateless na classe que implementa:

@Stateless
public class AgendamentoImpl implements Agendamento {
	// ...
}

Pronto, faça o deploy do projeto web no servidor Glassfish v3 e veja o seguinte log aparecer:

INFO: Bound Java:Global name [business view] : java:global/AgendaMedica/AgendamentoImpl#br.com.objectzilla.agendamedica.Agendamento
INFO: Bound Java:Global name [single business view] : java:global/AgendaMedica/AgendamentoImpl

Repare em como é realizado o binding com o JNDI. A partir da versão 6, não será mais uma implementação específica de contêiner. Todos os servidores de aplicações, se quiserem ser homologados para Java EE 6, deverão dispor seus EJBs, em contextos JNDI, de acordo com o seguinte padrão:

java:global[/<application-name>]/<module-name>/<bean-name>#<interface-name>

Onde:

<application-name> é opcional, refere-se ao nome do pacote EAR (não tem no nosso caso).

<module-name> é o módulo onde está o EJB (AgendaMedica).

<bean-name> é o nome do bean (AgendamentoImpl).

<bean-name> é o nome do bean (AgendamentoImpl).

<interface-name> é o nome completo da interface que implementa o bean (br.com.objectzilla.agendamedica.Agendamento).

O leitor atento deve ter reparado: está sendo feito dois bindings para o EJB! Isso também faz parte do padrão. Se o bean implementar apenas uma interface, um alias será criado onde o nome da interface não aparece.

Já que criamos o Session Bean, seria interessante se usássemos, não é não? Vamos fazer um Servlet, mas não precisa tomar o susto de configurar o wer.xml, pois basta criar um classe que herde de HttpServlet e adicionar uma anotação de acordo com o seguinte código:

@WebServlet(value="/agendamento")
public class AgendamentoServlet extends HttpServlet {
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
	}
}

Após o deploy, basta digitar http://localhost:8080/AgendaMedica/agendamento e você vai ver… uma tela em branco. Normal, a gente não fez nada mesmo. Agora, vamos preencher o doGet() com uma chamada ao método de marcarConsulta() de agendamento. Eu também injetei uma instância de EJB.

@WebServlet(value="/agendamento")
public class AgendamentoServlet extends HttpServlet {
 
	@EJB
	private Agendamento agendamento;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		String nomeMedico = req.getParameter("medico");
		String nomePaciente = req.getParameter("paciente");
		int hora = Integer.parseInt(req.getParameter("hora"));
 
		// criando médico
		Medico medico = new Medico();
		medico.setNome(nomeMedico);
 
		// criando paciente
		Paciente paciente = new Paciente();
		paciente.setNome(nomePaciente);
 
		// criando horário
		Calendar horario = Calendar.getInstance();
		horario.set(Calendar.HOUR, hora);
		horario.set(Calendar.MINUTE, 0);
		horario.set(Calendar.SECOND, 0);
 
		// chamando método de agendamento
		agendamento.marcaConsulta(medico, paciente, horario);
 
		PrintWriter pw = resp.getWriter();
		pw.format("Eu juro que marquei consulta para o paciente %s, com o médico %s, na hora %d.",
				medico.getNome(), paciente.getNome(), horario.get(Calendar.HOUR));
 
 
	}
}

Se você rodar http://localhost:8080/AgendaMedica/agendamento?medico=Jose&paciente=Adolfo&hora=14, vai ver que a aplicação mostra uma mensagem na tela que não diz se foi, ou não foi, feito algo. Precisaria de uma tela de consulta, mas só dá pra fazer isso se nossa aplicação persistisse os objetos entre as requisições, o que atualmente não ocorre.

Vou fazer isso no próximo post, onde apresentarei mais novos recursos e novas funcionalidades na aplicação pra que ela finalmente funcione de verdade.

Quem quiser, pode ir alterando a aplicação por conta própria, deixei no repositório GitHub em http://github.com/leonardoverissimo/javaee-6-application/tree/master.

Vamos à Mundo Java primeiro que, como sempre, está excelente. Hoje vi só a matéria sobre EJB e Spring (muito boa), porém houve um pequeno trecho que me deixou de estômago embrulhado (ênfases são minhas):

Anti-pattern em injeção de dependência
Com a facilidade e praticidade do EJB 3.0, alguns desenvolvedores acabam deixando de lado a preocupação com a escalabilidade e gerenciamento de recursos do container, anotando toda e qualquer classe do sistema para se beneficiar da injeção de dependência. Isso não é uma boa prática porque cada objeto anotado com @Stateless existirá um novo recurso para ser gerenciado pelo servidor de aplicações.

Um exemplo prático dessá má utilização de injeção de dependências no ambiente EJB é a implementação do design pattern Data Access Object (DAO) como um EJB. Dependendo do design do software, cada funcionalidade do sistema irá conter um DAO e essa funcionalidade será um Session Bean para se beneficiar do recurso de injeção de dependência do servidor de aplicações. Para evitar esse problema, uma solução seria injetar o EntityManager diretamente nos session beans, por meio da anotação @PersistenceContext, ou utilizar o design pattern Abstract Factory.

Primeiro, vamos à bronca: você não está programando em C, nem precisa ouvir os malucos que programam nessa linguagem. Fim da bronca.

Segundo, existe dois problema na definição de um Stateless Session Bean (SLSB): um que a anotação não é sobre o objeto (isso ainda não existe na linguagem), mas na classe; e dois que, quando você cria um SLSB, não há a criação de um recurso, mas de váááários recursos em pool. Se você olhar na configuração do Glassfish, verá que por default é possível ter até 1024 instâncias de SLSB no pool.

Terceiro, sabe qual a justificativa para isso ser um anti-pattern? Escalabilidade, só isso! Não é problema de code smell, de código que gera resultados imprevisíveis, de problemas de manutenção…, nem nada! Simplesmente ES-CA-LA-BI-LI-DA-DE! Agora, o pool de instâncias de SLSB não existe para se ganhar escalabilidade? Se tiver problemas com isso, vai nas configurações de seu servidor e mude os parâmetros do container EJB! Outra solução é comprar mais memória ou, se for mais sério, fazer load balance de mais de um servidor.

Pior ainda, a alternativa ao “anti-pattern” é “injetar o EntityManager diretamente nos session beans”, o que fatalmente acarretaria códigos macarrônicos com métodos gigantescos e difíceis de ler. Ou então, “[utilize] o design pattern Abstract Factory” que, pelo que já vi usado no contexto do EJB, é POG!; pois é usado um único EJB para o Factory, que devolveria os DAOs necessários, que por sua vez, tem código muito mais idiota para se pegar o EntityManager do que se fosse feito por SLSB!

Gente, use SLSB para DAO também! Que mal há nisso? Escalabilidade não é! Acho que no fundo, as pessoas sentem saudades do tempo em que cada camada tinha seu framework, tipo: era Struts para a apresentação, EJB para a camada de negócio, Hibernate para a persistância… Hoje estamos se aproximando da era onde os SLSB podem ser usados até na camada de apresentação (Seam / Web Beans)! E ninguém passou a escrever código horrível por causa disso! Por que raios ainda ficar nesse pensamento?

Vamos ao tópico do GUJ, maldito! (Não você que é maldito! O tópico!) (link) O cara parecia que quer defender com unhas e dentes que usar static é melhor que criar instâncias, polimorfismo…, enfim, essa coisa linda que é o OO.

Bom, o que sei é que usar static a torto e a direito no Java EE dá merda, pois é um static por class loader, e os servidores de aplicações possuem vários class loaders, cada um com potencialidade de carregar a classe e ter seu próprio static. Segundo, que com métodos static não dá pra fazer muita coisa que o Java EE oferece (EJB, por exemplo). Terceiro, que é idiota mesmo, coisa de gente que não sabe OO.

Agora, sabe a justificativa para usar static? O cara acredita que é mais rápido, simplesmente isso! Quer dizer, dava muito bem pra gerar um código bom, usando OO, e comprar uma máquina de configuração muito boa. Muito melhor do que se matar em otimizações minúsculas de veracidade duvidosa.

Aliás, vou dar um guideline para se fazer otimizações:

1. Pergunte ao cliente se está achando o sistema lento. Se a resposta for não, fim do guideline.

2. A compra de mais memória, mais disco ou mais blade custa menos que o pagamento de uma equipe de desenvolvedores? Se sim, vá na Santa Efigênia e fim de guideline.

3. Meça a duração usando vários casos possíveis.

4. Faça a alteração e meça de novo.

5. Se a nova medida não for muito menor que a medida antiga, jogue suas alterações no lixo e volte ao passo 4.

6. Caso contrário, comite a alteração e dê por encerrado (por enquanto).

Os dois casos me deixam perplexos: é como se para se justificar alguma coisa que não sabe bem o porquê, ao invés de ir mais a fundo e pesquisar, diz-se apenas que a altenativa “ruim” tem problemas de desempenho ou escalabilidade! Simples assim! E esquece que esses dois tipos de problemas está mais relacionado à arquitetura, à característica do sistema, ao “conjunto da obra” e muito pouco sobre a tecnologia ou o paradigma em si. Por muito escarcéu, muita gente escolhe o Barrabás.

Agora, por que as pessoas usam o argumento do desempenho / escalabilidade? Tenho duas teorias:

1. Alguns programadores aprenderam apenas uma determinada tecnologia em sua carreira. Quando esta tecnologia começa a sumir, eles passam a ter um certo desdém pelo novo, classificando pelos mais variados adjetivos. Alguns deles simplesmente não colam. Porém, o que, às vezes, fica marcado, é dizer que tal coisa não tem desempenho ou não tem escalabilidade, e por uma única razão: é difícil provar a menos que se meça com os próprios olhos. E como muita gente não faz isso, fica-se no benefício da dúvida.

2. Alguns programadores trabalham em ambientes péssimos de trabalho, a principal é a ausência de decisão e autonomia. Normalmente, as decisões são concentradas em pouquíssimas pessoas, e que nem sempre são as mais qualificadas. Os “artefatos” que saem das mãos dessas pessoas são os famosos diagramas de UML, bastando o programador codificar. (O mais imbecil nisso é que os “eleitos” escrevem diagramas tão detalhados que poderiam ter feito o negócio direto em código, e que haveria a mesma abstração. Mas não fazem código porque delegar essa atividade pra alguém é a melhor maneira de camuflar seus próprios erros.) E como o programador não tem a liberdade necessária para fazer seu trabalho, só lhe resta uma coisa intelectual para fazer: otimizar. Pena que será imperceptível para os olhos dos outros. Pena que o próximo a dar manutenção será ele mesmo.

Se eu tivesse a oportunidade, do tipo, sei lá: viesse um cara, chamado James e me dissesse:

Leo, seguinte, eu tô a fim de fazer uma nova linguagem aí e, sei lá, achei interessante forçar o tratamento de exceções pra que ninguém esquecesse de tratá-lo, tipo uma exceção checada. O que você acha?

Minha resposta:

Horrível!

Sim, existe um limite prático pra tipagens verificadas por compilador, o aumento da complexidade. Isso certamente acaba complicando mais pra quem começa na linguagem. Mas enfim, já que não me consultaram…. o melhor é usá-las, e usá-las com sabedoria.

Mas Leo, como seria?

Boa pergunta. Uma definição legal é do livro Effective Java, que diz, na página 244:

… use checked exceptions for conditions from which the caller can reasonably be expected to recover… use runtime exceptions to indicate programming errors…

Lendo essas duas definições, pode parecer confuso, veja o que alguém poderia pensar: “Exceção checada só ocorre quando há erros de programação. Nunca cometo erros, logo sempre usarei exceções checadas!”

Não, não e NÃO!!!

Pra entender o que é um erro de programa, você deveria entender que os métodos de seus objetos só podem ser executados se determinadas pré-condições sejam satisfeitas. O problema é que miuta gente também nunca ouviu falar em pré e pós-condições. E dos que ouviram, aplicam de um jeito errado. Meu, vou contar uma história: uma vez eu estava vendo um “documento” de “caso de uso” e lá tinha a seção “pós-condições”. Em todas as vezes, juro, em TODAS as vezes, estava escrito: “Pós-condição: caso de uso executado com sucesso.”. O que?! Significa que é uma condição sine qua non de que NUNCA vai dar falha?

Vamo lá: pré-condição e pós-condição refere-se ao mundo externo do método (ou do fluxo ou do processo, depende do seu ponto de vista). Pré é como o estado do “mundo” deve estar antes da execução. Pós é como o “mundo” irá ficar.

Exemplo: um método de inserção. A pré-condição é de que o objeto exista e que seja de um tipo específico. A pós-condição é que no banco existirá um registro a mais, ou ficará como antes (em caso de erro).

E se eu chamar o método e a pré-condição não estiver sido respeitada? Erro! O método nem é chamado. E se a pós-condição não for respeitada? Erro também! O sistema, pelo menos, deve voltar ao estado anterior da execução.

Claro que isso não é implementado nativamente nas linguagens mais populares, nem nas mais-ou-menos populares. Em Java, por causa disso, você trata as pré-condições usando exceções. (As pós poderiam ser a captura de exceções de outros métodos que o método chama.) E como violação de pré-condição é um erro, você usa exceção não-checada, pois esta deve ser usada em caso de erros de programa.

Quer ver um exemplo de onde se usa exceção não-checada como violação de pré-condição? HttpServletResponse! Existe uma condição que é o seguinte: uma vez aberto um OutputStream ou um Writer, não se pode abrir um outro stream, nem executar um forward. O que acontece quando alguém, “sem querer”, comete essa cagada esse erro?

É lançada uma exceção não-checada, a IllegalStateException.

Como guia: use exceções não-checadas quando o chamador tem meios de checar se os parâmetros ou o estado do objeto estão corretos antes da execução do método (claro, não é uma ciência exata, podem haver, err…, exceções). No caso acima, a pessoa poderia muito bem verificar se, no Response, é possível criar um novo fluxo chamando o método isCommitted().

E quando usar exceções checadas? Existem casos em que o método não tem qualquer meio de verificar determinada pré-condição, ou tem mas o meio de verificar é praticamente a própria execução do método. O chamador então deve se arriscar chamando o método, e este deve dizer depois se deu certo ou não, lançando exceção, checada!

Exemplo: método parse() de DateFormat, que vai pegar uma String, e devolver a representação dela como um Date. Repare que é lançando exceção checada ParseException caso a String não seja uma data. Por que exceção checada? Porque verificar se uma String é realmente uma data não é tarefa trivial, não dando pra contar com uma verificação prévia antes da execução do método. Por outro lado, parseInt() da classe Integer não lança exceção checada, pois é possível facilmente verificar se uma String contém somente números.

Outro exemplo são os métodos write() de BufferedWriter ou prepareStatement() de Connection que lançam exceções checadas por uma razão simples: nem o chamador nem o método tem a mínima noção se o sistema de arquivos ou o banco de dados está em condições de realizar a ação desejada (e verificar isso pode resultar em outra exceção!).

Como guia: use exceções checadas quando o chamador precisa tomar uma “rota alternativa” após o método ser chamado, pois não dá pra evitar o pior antes.

Uma outra coisa, nem sempre dá pra saber a priori se determinada exceção deveria ser checada ou não. Se você criou uma exceção checada, mas seus chamadores não fazem outra coisa a não ser relançar a exceção ou fazer o log dele, é porque você tem que converter a exceção checada em exceção não checada! Exceções checadas é para quando o chamador precisa tomar uma atitude a respeito. Se nenhum chamador precisou fazer isso, é porque, muito provavelmente, a exceção nunca precisaria ser tratada e o lançamento dela significa simplemente um erro de programa.

Outra coisa, exceções precisam ter nomes significativos. Evite as famosas “exceções arquiteturais” ou “exceções de camadas”, que você identifica por DaoException, BusinessException, ApplicationException ou NomeDaEmpresaException. Todas elas não dão significado ao erro que ocorreu e o programador certamente não irá tratá-las adequadamente, pois não tem a mínima idéia do que fazer, dada a ausência de informações contidas nessa exceção.

E evite criar novas exceções quando existem algumas delas já prontas pra você, como é o caso de NullPointerException (sim, se você receber um parâmetro nulo, não há problema nenhum em você lançar essa exceção, colocando uma mensagem talvez), IllegalArgumentException ou IllegalStateException. Elas não são exclusivas das bibliotecas Java, nem são exceções reservadas. Use-as quando for o caso.

C++ tem closure? Como assim? Viajou, né? Bom, vou tentar fazer algo, só não sei se vai dar certo. A minha idéia é fazer uma classe Observer onde é possível registrar uma closure. Quando for chamado a função notify() do objeto dessa classe, a closure será chamada e esta terá inclusive referencia de um contexto que não existe pro objeto Observer.

Primeiro, criei a classe SimpleObserver (pois só armazena uma closure por vez e não se aproveita de template). Todo o conteúdo do fonte está em um arquivo hpp (simple_observer.hpp):

#ifndef _SIMPLE_OBSERVER_H_
#define _SIMPLE_OBSERVER_H_
 
#include <boost/function.hpp>
 
class SimpleObserver {
 
    public:
        /* armazena uma função sem parâmetros que retorna void */
        void registry(const boost::function<void (void)>& cb)     { callback = cb; }
        /* invoca a função previamente armazenada */
        void notify()                                             { if (callback) callback();    }  
 
    private:
        boost::function<void (void)> callback;
};
 
#endif

Simples, não? Um método pra armazenar uma função, outro pra chamá-lo. Repare que eu usei uma classe do Boost, function, que serve para guardar funções de qualquer tipo. No caso limitei para retorno void e nada de parâmetro de entrada. Outra coisa, pra quem não conhece C++, a expressão if(callback) parece estranho. O que ocorre é que nessa linguagem, é possível um objeto ser implicitamente convertido pra outro tipo (contanto que o programador escreva a função de conversão, claro!), e, no nosso caso, a biblioteca converte o objeto function pra um outro do tipo bool. “Mas pra que?”, você pensa. Bom, é comum um objeto inválido ser sempre convertido como false, e um válido como true; e nesse caso, o objeto é inválido se o objeto function não apontar pra nenhum ponteiro de função.

Agora, vou mostrar a classe que vai criar uma closure, a Event, em dois arquivos, a event.hpp

#ifndef _EVENT_H_
#define _EVENT_H_
 
#include <map>
#include <boost/function.hpp>
 
class Event {
 
    public:
        /* construtor que recebe um número como argumento */
        Event(const long& value);
 
        /* retorna uma função, que leva em consideração o valor de entrada
           e a própria instância */
        boost::function<void (void)> create_closure(std::map<std::string, long>& parameter_value);
 
        long instance_value() { return this->inst_value; }
 
    private:
        void callback_function(std::map<std::string, long>* param, long local);
 
    private:
        long inst_value;
};
 
#endif

É uma classe que tem um construtor que recebe um valor (daqui a pouco você vai ver que esse valor é atribuído à única variável de instância da classe). A função create_closure() retorna uma “function” recebendo um map. A função instance_value() simplesmente mostra o valor da variável de instância. Existe uma função privada, a callback_function que usarei como ponteiro da minha closure.

Vamos à event.cpp:

#include "event.hpp"
#include <boost/bind.hpp>
 
Event::Event(const long& value)
    : inst_value(value) {}
 
boost::function<void (void)>
Event::create_closure(std::map<std::string, long>& parameter) {
 
    long local_value = parameter["value"] + 5;
 
    return boost::bind(&Event::callback_function, this, &parameter, local_value);
 
}
 
void 
Event::callback_function(std::map<std::string, long>* param, long local) {
    (*param)["value"] += 6;
    this->inst_value += local;
}

A função create_closure() faz uma soma qualquer, criando uma variável local. Depois é usado o bind(), também do Boost, para reduzir uma função com três parâmetros (o “this” mais os dois parâmetros “normais”) para uma função com zero parâmetros. Essa função, a callback_function, não faz nada mais do que um cálculo.

Pra finalizar, criei o arquivo main.cpp com a função que chama todo mundo:

#include "simple_observer.hpp"
#include "event.hpp"
 
#include <iostream>
 
using namespace std;
 
int main(int argc, char** argv) {
 
    SimpleObserver observer;
 
    Event event(10);
 
    std::map<std::string, long> parameter;
    parameter["value"] = 8;
 
    observer.registry( event.create_closure(parameter) );
 
    observer.notify();
 
    cout << "Instance value = " << event.instance_value() << endl;
    cout << "Parameter      = " << parameter["value"] << endl;
 
}

Eu tenho o Ubuntu, e usei o apt-get pra pegar uma versão da biblioteca Boost e, obviamente, o g++. Como o gerenciador de pacotes vai colocar os HPPs num lugar visível, basta apenas executar o comando:

 c++ -O3 event.cpp main.cpp -o closure

Lá na método main, eu chamei tudo mundo, crio o observer, crio o objeto event, e peço a este um closure a ser passado para o observer. Quando o observer for notificado, a instância de event é alterado, assim como o parâmetro passado.

Mas repare uma coisa, eu menti para vocês! C++ não possui suporte a closures! Lá no método create_closure(), tive que passar o “contexto” (parâmetros, variáveis locais, a própria referência this) explicitamente com o “bind”. E por não ter garbage collector, não há nem garantia de que os objetos passados com bind realmente exista na sua execução. Portanto, nem tente fazer algo parecido.

Eu comecei com C++ porque é a “pior implementação de closures” das linguagens que eu conheço. Mas não se preocupe, em um próximo post, vou mostrar closure em uma outra linguagem, só que dessa vez, de verdade!

Primeira coisa: em linguagens que suportam closures, funções são tratadas como dados, ou seja, tem a mesma semântica que um inteiro, uma string, um objeto… Isso é diferente de linguagens onde closures não existem, como Java, em que a função é definida estaticamente, e de lá não sai. Na verdade, no nível da máquina, tanto dados quando procedimentos são representados por um endereço de uma região de memória, são as linguagens sem closures que abstraem variáveis e funções como sendo coisas distintas.

Em linguagens procedimentais, como C, existe o conceito chamado ponteiro de função que, basicamente, é a obtenção de uma referência de uma função pra ser executada em um tempo posterior. O uso de ponteiro de função é bastante baixo nível, e é utilizado bastante, por exemplo, no Linux, já que os módulos, os callbacks e os próprios processos são executados dinamicamente, de acordo com a vontade de seus usuários.

Porém, pra muitos, a simples referência de uma função não se caracteriza uma closure. Principalmente em linguagens orientadas a objetos, closure é associada à captura de um contexto onde a closure é definida. A função closure captura sempre as referências do objeto e do método que a criou pois a qualquer momento pode chamar uma de suas variáveis ou de seus métodos, ou seja, ela “fecha” o contexto (daí o nome closure, ou “fechamento”). Parece esquisito, mas na prática, essa característica faz com que você sinta que o escopo “é o de menos” e que possa usar os métodos e variáveis disponíveis, sem se preocupar depois se o contexto vai desaparecer ou não. É como se, depois de declarada a função, houvesse uma variável invisível que tivesse a referência de tudo o que está externo e que, portanto, poderia usá-lo enquanto a função existir. Pense, por exemplo, nas inner class do Java, você simplesmente não consegue chamar qualquer variável do objeto mais externo, a menos que esteja marcado final. Porém, em linguagens com closures, não existe uma restrição como essa.

Closures, por serem também um dado, costumam ser transportados de uma variável à outra, passando por vários contextos diferentes.

Vamos a um exemplo: na linguagem Ruby, eu poderia definir uma função e associá-la a uma variável:

quadrado = lambda do |x|
  x * x
end

Por ser um dado, então atribuí-la a uma outra variável é possível:

funcaoMisteriosa = quadrado

E tanto “quadrado” quanto “funcaoMisteriosa” possuem a referência à mesma função. E ambos são capazes de avaliar a função, veja:

puts quadrado.call(4)    # 16
puts funçãoMisteriosa.call(4)  # 16

Isso por si só não é uma closure. Como dito antes, a linguagem C possui a capacidade de transportar ponteiros de funções, e é apenas isso que eu estou fazendo. Eu poderia, em Ruby, utilizar variáveis e métodos do contexto mais externo, mesmo que este não estivesse visível no momento em que a função fosse realmente executado. Como exemplo, imagine que uma função é declarada em uma classe, e que fosse possível passar pra um outro objeto:

# essa classe só tem um método que vai
# executar o bloco recebido
class Bar
  def execute(bloco)
    puts bloco.call(10)
  end
end
 
class Foo
  def initialize(atributo)
    @atributo = atributo
  end
 
  def teste()
    # criei uma função e associei à variável funcaoQualquer
    # repare que a função tem uma instância de uma variável pertencente
    # a esse objeto (atributo)
 
    blocoQualquer = lambda do |x|
      @atributo + x
    end
    # criei um objeto...
    bar = Bar.new
    # ...e passei a variável contendo a função
    bar.execute(blocoQualquer)
  end
end
 
# crio o objeto passando 5 como attributo
foo = Foo.new(5)
# chamo teste, que vai criar um bloco e chamar execute de um outro objeto,
# que por sua vez, vai imprimir uma soma (o resultado é 15). Repare que foi
# utilizado, na sua execução, uma variável (@atributo) que o objeto do tipo
# Bar não conhece, mas que está no contexto do bloco passado (houve a closure).
foo.teste

Foi possível chamar a variável @atributo porque, ao declarar o bloco “blocoQualquer” foi feita a captura do contexto em volta; como, por exemplo as variáveis do método Foo#teste e os atributos de instância do objeto Foo.

Cada linguagem tem seu jeito de chamar uma closure. Por isso, nos próximos posts, vou dar exemplos em algumas delas. Aguarde.

UPDATE:
Essa série sobre Closures continua aqui, e aqui.