Artigos Java Revisitando Internacionalização – Parte 2
Artigo do tipo Exemplos Práticos
Recursos especiais neste artigo:
Artigo no estilo Curso Online
Revisitando Internacionalização – Parte 2
Dando continuidade à Parte 1 do artigo, na qual mostramos uma metodologia para organizar a disposição e o acesso a mensagens de I18N, apresentaremos algumas extensões para que a técnica possa ser empregada de forma consistente em ambientes de publicação heterogêneos. Analisaremos efeitos colaterais que ocorrem ao se colocar referências para conteúdo textual constante em campos de classes e como a estratégia de criação de mensagens desenvolvida previne que estes se manifestem e gerem impactos negativos, tais como a duplicação desnecessária de Strings e a consequente elevação do consumo de memória de uma aplicação.

Em que situação o tema é útil
Este tema é útil para desenvolvedores que gostariam de organizar os textos de uma aplicação cuja exibição é condicionada a uma determinada linguagem, utilizando os mesmos de forma simples nas camadas de negócio e apresentação, com os benefícios da expressividade e exatidão proporcionados por uma abordagem fortemente tipada.

Na primeira parte do artigo apresentamos uma estratégia para encapsular mensagens de internacionalização. Esta técnica consiste em associar um conjunto de Strings (já traduzidas para um determinado Locale) com métodos declarados em uma interface, utilizando a API do ASM para automatizar a geração da respectiva implementação. Esses objetos podem ser obtidos de forma programática ou referenciados de forma transparente em uma aplicação web gerenciada por um contêiner CDI.

Nesta parte do artigo veremos como a geração de código pode ser estendida de forma a contemplar algumas situações que são relevantes em ambientes de publicação de aplicações web ou corporativas e também para podermos trabalhar com métodos parametrizados utilizando tipos arbitrários (int, double, etc.), o que certamente melhora a compreensão do código acerca de quais valores devem ser utilizados para se formatar e exibir uma mensagem.

Por fim, veremos como podemos criar as classes de mensagens em tempo de compilação (ao invés de em tempo de execução), de modo que as mesmas possam ser referenciadas no classpath de uma aplicação, o que é mais apropriado em ambientes de produção.

Refinando a geração de código

Conforme vimos na edição anterior, nossa estratégia para a construção de mensagens de I18N é baseada em geração de código, o que nos poupa do trabalho mecânico de criar classes apenas para guardar valores fixos. Anteriormente apenas nos preocupamos em fazer a associação [Texto Traduzido]<=>[Método de Interface], que é suficiente para ser utilizado, por exemplo, em uma aplicação web gerenciada por CDI. Como o intuito é poder utilizar esta técnica em frameworks para aplicações Java EE, devemos nos preocupar tanto com características da especificação (ex.: criar referências serializáveis), como com aspectos não-funcionais, tais como não gerar overheads desnecessários pela introdução de um componente novo. Os próximos subtópicos discutem como essas peculiaridades também podem ser automatizadas no processo de construção das classes pela API do ASM.

Singletons: Minimizando o número de instâncias

Embora criar uma instância das classes geradas seja uma operação muito “barata”, pois as mesmas não possuem qualquer estado (todas as Strings são referenciadas diretamente nos métodos como se estivessem “hard-coded” e não são atribuídas a campos), podemos fazer uma pequena otimização de forma que apenas um único objeto seja instanciado para cada [Interface,Locale].

Para evitar que o método resolve() da classe I18NRepository (Listagem 8 da Parte 1) crie um novo objeto toda vez que for invocado, podemos tratar as classes construídas pelo gerador de código como Singletons, ou seja, precisamos que as mesmas contenham uma instância estática de seu próprio tipo, como demonstra a ...

Quer ler esse conteúdo completo? Tenha acesso completo