Michel Zanini

Em muitos casos será necessário criar um objeto no ApplicationContext que não é um Java Bean. Ou em alguns casos, é necessário executar algum método de inicialização no objeto criado, ou algum procedimento customizado. Para esses casos o Spring possuí o conceito de FactoryBean.

FactoryBean é uma interface que possui três métodos para implementar, como visto a seguir:

Na maioria dos casos é mais adequado estender a classe abstrata AbstractFactoryBean que implementa a interface acima. Por default, ao estender essa classe o objeto criado é um singleton, que é o mais comum na maioria dos casos. Na AbstractFactoryBean restam os métodos ‘getObjectType’ e ‘createInstance’ para implementer. O ‘createInstance’ difere do ‘getObject’ pois só é chamado uma única vez (para singleton’s), e varias vezes para prototypes.

Como exemplo, vamos criar uma classe ‘KeyStoreFactoryBean’ que implementa essa interface. O objetivo é a criação de KeyStore’s de forma prática dentro do ApplicationContext. Note que um KeyStore não é um Java Bean, portanto essa é uma maneira adequada de permitir injetar KeyStore’s dentro de outros objetos do ApplicationContext. Portanto, começamos com uma implementação inicial:

A instância retornada será do tipo java.security.KeyStore e poderá ser injetada em qualquer setKeyStore(KeyStore) de outro Java Bean do ApplicationContext. Veja um exemplo desse bean declarado no ApplicationContext:

Para tornar nosso exemplo realista vamos tornar o KeyStoreFactoryBean configurável. Para isso vamos adicionar quatro propriedades. O local que o arquivo KeyStore está (podendo ser no classpath, filesystem, URL, etc), uma senha para abrir o KeyStore, o tipo de KeyStore (ex: pkcs12, jks, etc) e o provider a ser utilizado. Os últimos dois parâmetros assumem valores padrões do Java, conforme esperado.

O código interessante é a implementação do método ‘createInstance’. Aqui criamos um KeyStore de acordo com os parâmetros passados. Veja o exemplo completo:

Repare na utilização da classe ‘org.springframework.core.io.Resource’ do Spring. Ela permite injetar qualquer arquivo, estando no classpath, no filesystem, URL, etc. Isso facilita a configuração.

Dessa forma é possível criar um KeyStore dessa forma no ApplicationContext:

Como vimos, um FactoryBean pode auxiliar em muito a criação de objetos difíceis de configurar. É muito utilizado para configurar objetos de frameworks externos dentro do Spring.

OBS: O exemplo completo da classe KeyStoreFactoryBean pode ser encontrado no módulo ws-security do projeto spring-ws, sub-projeto do springframework.

Abraços,
Michel Zanini.

No link about do site do spring é possível encontrar os objetivos propostos pelos desenvolvedores do framework:

1. J2EE should be easier to use
2. It is best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.
3. JavaBeans offer a great way of configuring applications.
4. OO design is more important than any implementation technology, such as J2EE.
5. Checked exceptions are overused in Java. A framework shouldn’t force you to catch exceptions you’re unlikely to be able to recover from.
6. Testability is essential, and a framework such as Spring should help make your code easier to test.

Gostaria de comentar o meu ponto de vista sobre cada um dos pontos levantados:

1. Na época em que o framework surgiu, em meados de 2003, desenvolver aplicações J2EE era uma tarefa árdua. Para reduzir essa complexidade, o Spring trouxe o conceito de POJO programming Model. Segundo esse modelo o desenvolvedor não é obrigado a implementar ou estender nenhuma classe, de nenhum framework ou API. Toda infra-estrutura necessária é realizada de forma transparente e não intrusiva. O Spring também trouxe o conceito de Template, uma classe que implementa o desing pattern Template Method. Os templates do Spring são usados para evitar o chamado “boilerplate code” (código repetitivo), como a utilização de API’s JDBC, JPA, JMS, JNDI, e etc. Os templates reduzem drasticamente a quantidade de código necessário. Somado a isso tudo, ainda temos as vantagens da utilização de injeção de dependências. Portanto, pós Spring, acredito que o Java EE se tornou muito mais simples.
2. Esse item é uma prática muito importante da programação OO. O Spring facilita a utilização de interfaces, pois não é necessário escrever a inicialização da classe concreta (operador new), é possível injetar a dependência em um objeto o qual dependerá apenas da interface.
3. Como mencionado no item um, o Spring trouxe o conceito de POJO programming Model pois isso simplifica muito a aplicação. É simples para qualquer iniciante entender a idéia de “JavaBean” e saber programá-la.
4. Esse é o item mais importante de todos em minha opinião. A programação OO deve prevalecer SEMPRE em relação a qualquer tecnologia utilizada, independente de quem a criou. Se você está utilizando EJB 2.x e eles te obrigam a criar código não OO, pense novamente. Procure os frameworks que são menos intrusivos o possível. Essa é a nova tendência que está sendo seguida por todos os projetos. Por exemplo: o Struts 2.x não depende mais da API de Servlets. O JUnit 4.x não necessita mais implementar uma super classe, pode-se utilizar anotações. Os “backing beans” do JSF são POJO’s. No EJB 3.x também não é mais necessário implementar interfaces, ou estender classes. E assim por diante. Essa abordagem facilita a aplicação de testes de unidade, e mais importante, facilita a posterior migração de API’s/tecnologias de forma menos traumática. O Spring é muito bom nesse ponto. O código fonte do framework é EXTREMAMENTE orientado a objetos e, é sempre possível utilizar seus recursos sem depender de suas classes.
5. Mais um item importantíssimo. Varias API’s feitas dentro do JDK ou JEE foram muito mal projetadas. O tratamento correto de exceções é raramente bem feito por programadores Java, pois se utiliza muito de exceções checadas. Em certos casos, como um acesso JDBC, não há muito o que uma aplicação possa fazer ao receber uma SQLException. O mesmo para RemoteException obrigatória em uma interface RMI, essa ainda mais danosa, pois fixa o cliente a conhecer a origem remota do objeto, dificultando a programação OO. O Spring criou para cada Template uma hierarquia de exceções não checadas. Assim, os métodos dos templates sempre lançam a exceção correta, e mais específica, sendo que você não é obrigado a criar nenhum bloco try-catch. Por exemplo, num código JDBC você pode, se quiser tratar uma exceção de integridade referencial, fazer um catch por “DataIntegrityViolationException” e o catch só será executado sobre essas condições. Bem melhor do que tentar “traduzir” uma SQLException.
6. Como comentado no item quatro. Aplicando uma boa programação orientada a objetos e utilizando frameworks não intrusivos, o código fica simples de testar. Um POJO é sempre facilmente testável. Com elaboração de testes de unidade seu código ficará muito mais confiável e trará uma economia de tempo e dinheiro, por pegar os maiores BUG’s ainda em etapa de desenvolvimento.

Um ponto não mencionado, que também gostaria de destacar, são as vantagens de trazer a Programação Orientada a Aspectos (AOP) para o dia a dia do desenvolvedor. A AOP ainda é pouco conhecida pelo usuário final e isso é um fato lamentável. Acredito que a AOP é uma grande ferramenta disponível a um desenvolvedor, e o Spring traz esse “poder” de forma prática e integrada.

Em um próximo post vou falar sobre os Templates disponíveis no Spring e qual a idéia básica por trás deles. Também irei voltar a falar sobre POJO Programming Model e unit testing.

Abraços,

Michel Zanini.