Introdução ao padrão Injeção de Dependências

Quando programamos temos que pensar bem em nossas classes, nos papéis aos quais estas representarão em nossa aplicação. À medida que vamos criando estas classes, como por exemplo, em uma aplicação de pagamentos, criamos uma classe ProcessadorPagamentos e esta poderia ter a necessidade de uma ligação com a classe SincronizadorPagamentos. Esta ligação torna a classe ProcessadorPagamentos dependente de SincronizaPagamentos. Por ter a necessidade desta dependência, ProcessadorPagamentos deveria saber como obter uma instância de SincronizaPagamentos, para assim poder utilizá-la.

O padrão de projeto Injeção de Dependências (Dependency Injection – DI) visa manter o fraco acoplamento entre tais classes dependentes, fazendo com que ProcessadorPagamentos não precise saber como instanciar SincronizadorPagamentos. Assim, esta classe se preocupa apenas em como irá utilizar SincronizadorPagamentos, em como será o negócio associado a esta interação, cabendo ao contêiner conhecer a forma de instanciar esta dependência e disponibilizá-la no momento necessário.

As injeções de dependências são uma forma de realização do padrão de Inversão de Controle (IoC), onde neste caso, o controle de construir objetos é invertido e passa a ser uma responsabilidade do contêiner, ou de algum componente que possa assumir este controle, e não mais do implementador.

A utilização da injeção de dependências se tornou amplamente difundida, desde 2003, com a utilização corporativa do framework Spring, que se baseia nos dois padrões citados anteriormente. Atualmente o projeto Spring Framework possui outras frentes além da injeção de dependências, atuando também na parte de acesso a dados, segurança, mobile e de integração com redes sociais.

Existem também outros frameworks conhecidos no mercado de injeção de dependências, são eles PicoContainer e o Google Guice, mas até então não existia uma especificação Java que padronizasse o uso de injeção de dependências em nossas aplicações.

No entanto, em dezembro de 2009, apoiada nas especificações da JSR 330 (Injeção de Dependência para Java) e JSR 316 (Especificação dos Managed Beans), foi disponibilizada a JSR 299, a especificação Java para Contextos e Injeção de Dependências, conhecida como CDI, ou Web Beans, ficando esta especificação associada ao Java EE (Java Enterprise Edition) 6.

Os serviços fundamentais providos pelo CDI abrangem Contextos, para controle de ciclo de vida e interações dos componentes de forma bem definida, e Injeção de Dependências, para a injeção typesafe de componentes em aplicações, ou seja, livre dos erros de tipagem, incluindo a capacidade de escolher no momento da implantação, qual implementação de uma interface específica será utilizada na injeção.

Além disto, podemos destacar:

• Integração com Expression Language (EL), permitindo que qualquer bean do CDI possa ser exposto em uma página JSF ou JSP;
• Utilização de métodos Produtores (conceito criado no CDI, que será abordado logo à frente), que atuam nas injeções de maneira polimórfica em tempo de execução;
• Utilização de Alternativos, que são marcações para auxiliar o contêiner a definir qual bean injetar, atuando em tempo de implantação.

Deste modo, ao longo deste artigo veremos como diminuir o acoplamento de nossas aplicações, utilizando os conceitos de DI, aliando seus benefícios à facilidade de uso da especificação do CDI.

Um novo conceito de Beans

Ao longo do uso de tecnologias Java você já deve ter ouvido falar em Java Beans e Enterprise Java Beans (EJB). Com CDI, o conceito de um bean foi um pouco além do usado nestas tecnologias. Nele, um bean é uma fonte de objetos contextuais que definem o estado e/ou lógica de um aplicativo. Assim, um componente Java EE é um bean se o ciclo de vida de suas instâncias pode ser gerenciado pelo contêiner, de acordo com o modelo de contexto do ciclo de vida que é proposto pela especificação CDI.

Sendo assim, com pouquíssimas exceções, quase toda classe Java concreta que possui um construtor com nenhum parâmetro (ou um construtor designado com a anotação@Inject) é um bean. Isso inclui qualquer Java Bean e qualquer EJB Session Bean. A seguir temos os tipos de objetos que podem ser injetados:

• A maioria das classes Java;
• Session Beans;
• Recursos Java EE (data sources, tópicos Java Message Service, filas, fábricas de conexões);
• Contextos de Persistência (Persistence Context – objetos JPA EntityManager);
• Objetos retornados por métodos produtores, ou criados por campos produtores;
• Referências a Web Services;
• Referências remotas de Enterprise Beans.

Definindo escopos com CDI

O escopo de um bean determina além do ciclo de vida de suas instâncias, os clientes responsáveis por determinadas instâncias de um bean. Assim conseguimos obter o controle de qual cliente possui um ciclo de vida de requisição, sendo renovado a cada solicitação de requisição, ou qual possui um ciclo de vida de sessão, armazenando os dados ao longo da duração desta sessão.

De acordo com a especificação CDI, um escopo determina:

• Quando uma nova instância de qualquer bean com esse escopo é criada;
• Quando uma instância existente de qualquer bean com esse escopo é destruída;
• Quais referências injetadas referem-se a qualquer instância de um bean com esse escopo, ou seja, se temos um bean XYZ com escopo de sessão, todos os beans que são chamados no contexto da mesma sessão HTTP verão a mesma instância do bean XYZ.
...
Quer ler esse conteúdo completo? Tenha acesso completo