Injeção de dependências em aplicações Android

A injeção de dependências (DI) ou Inversão de Controle (IoC) são termos utilizados como sinônimos, no entanto, o termo IoC é aplicado dentro e fora do contexto de injeção de dependências. Esta terminologia refere-se à inversão da responsabilidade que uma classe tem de buscar e controlar suas próprias dependências. A inversão faz com que essa responsabilidade seja transferida a um framework capaz de buscar as dependências automaticamente. Ou seja, o controle sobre as dependências é invertido – deixa de ser implementado pelo desenvolvedor e passa a ser gerenciado por um componente especializado. Essa característica de inversão pode ser empregada a qualquer framework que retire a responsabilidade do programador de codificar um determinado código para realizar uma tarefa específica.

Um framework de injeção de dependências, ou contêiner IoC, é capaz de construir desde um simples objeto até uma longa cadeia de objetos dependentes entre si.

A injeção de dependências implementada pelos frameworks mais populares soa como mágica pela maneira transparente de instanciar e atribuir objetos aos locais que são requisitados. Fazendo uma analogia com o mundo real, é possível imaginar que ao invés caminhar todos os dias para comprar pão e tomar café, seria bem mais fácil se o pão aparecesse em cima da mesa, não seria?

Em um sistema de pequeno porte o esforço para instanciar manualmente cada uma das classes envolvidas e atribuí-las ao local correto pode até ser trivial, mas à medida que o sistema cresce, outros requisitos surgem, a complexidade aumenta e a tarefa de manter todos os objetos corretamente construídos e relacionados torna-se mais onerosa para o programador, além de ser bastante suscetível a falhas por qualquer esquecimento.

A injeção de dependências é uma solução que proporciona transparência na construção dos objetos envolvidos, possibilitando desacoplar e variar a implementação sem necessariamente codificar para isso. No entanto, alguns problemas podem surgir se os padrões citados anteriormente não forem seguidos como, por exemplo, a dependência circular, que ocorre quando dois objetos dependem um do outro para inicializarem. Perceba que o simples fato de um objeto depender do outro não é exatamente uma limitação que a injeção de dependências seja incapaz de atender, contudo, na maioria das vezes este cenário não é um bom desenho OO e se ambos os objetos necessitarem da execução de um código de inicialização, o contêiner IoC não poderá determinar quem chamar primeiro. Esta situação hipotética fere o princípio do baixo acoplamento, pois um objeto impacta diretamente no comportamento do outro, ocasionando um fluxo de comunicação anormal entre eles.

Apesar da injeção de dependências ter se tornado uma alternativa popular para fazer ligações indiretas entre objetos, o padrão Service Locator costumava ser uma solução bastante utilizada para o mesmo problema. Nesta abordagem, a atribuição de descobrir e criar objetos é delegada a uma classe que centraliza a instanciação ou procura (lookup) dos objetos. Assim, toda classe chama diretamente o Service Locator para obter uma instância de outro objeto que ela dependa. Desta forma, este centralizador termina acoplado com todas as classes do sistema, o que não é um desenho orientado a objetos apropriado. Devido a este efeito colateral, o Service Locator vem caindo em desuso e abrindo lugar para a injeção de dependências. Entretanto, no âmbito da API do Android, o Service Locator ainda é um padrão muito utilizado. Isso se deve à antiguidade da API, que é evoluída sempre um passo antes em relação à evolução do Java, linguagem na qual as aplicações Android são desenvolvidas.

Após esta contextualização sobre o padrão de projeto Injeção de Dependências, será apresentado um exemplo de utilização do RoboGuice em um projeto demonstrativo. No entanto, antes de iniciar o projeto, iremos entrar em uma breve explicação sobre o ambiente de desenvolvimento, com o qual será desenvolvido o exemplo.

"