Para quê você tem usado Injeção de Dependência(Dependency Injection)?

Vi na InfoQ um artigo intitulado: Does Dependency Injection pay off? Nesta URL.

Um comentário contido nele me foi curioso:

Jacob Proffitt wrote:The real reason that DI has become so popular lately, however, has nothing to do with orthogonality, encapsulation, or other ?purely? architectural concerns. The real reason that so many developers are using DI is to facilitate Unit Testing using mock objects. Talk around it all you want to, but this is the factor that actually convinces bright developers to prefer DI over simpler implementations.

Ou seja, o cara diz que só ficou popular pq a galera usa para fazer testes unitários.

Eu não utilizo DI embora tenha lido uma coisa ou outra a respeito. Mas gostaria de saber de vocês( e isso vai ser muito enriquecedor para mim). Para quê você usa Injeção de Dependência(Dependency Injection)?

This message was edited 1 time. Last update was at 17/12/2007 19:15:36

Nós usamos para fazer aplicações orientadas a plugins (aqui falando mais de IoC) e testes unitários.

Mas a grande questão também é... não são os testes unitários um benefício grande o suficiente para justificar a DI?

This message was edited 2 times. Last update was at 17/12/2007 19:22:56

Em contextos do tipo statefull isso é quase obrigatório para o programador não ficar repetindo código para pegar os beans da seção. Porém, nesse caso não é muito útil sem bijeção, ou seja, além de injetar as dependências também tem que "ejetar" (aplicar as alterações feitas sobre bean pela action).

bobmoe wrote:Em contextos do tipo statefull isso é quase obrigatório para o programador não ficar repetindo código para pegar os beans da seção. Porém, nesse caso não é muito útil sem bijeção, ou seja, além de injetar as dependências também tem que "ejetar" (aplicar as alterações feitas sobre bean pela action).

Mas, nesse caso, pq outros padrões não seriam igualmente úteis. Entre eles strategy, registry ou, como cita o autor do artigo original, o provider?

ViniGodoy wrote:

bobmoe wrote:Em contextos do tipo statefull isso é quase obrigatório para o programador não ficar repetindo código para pegar os beans da seção. Porém, nesse caso não é muito útil sem bijeção, ou seja, além de injetar as dependências também tem que "ejetar" (aplicar as alterações feitas sobre bean pela action).

Mas, nesse caso, pq outros padrões não seriam igualmente úteis. Entre eles strategy, registry ou, como cita o autor do artigo original, o provider?

No Registry acho que ainda é necessário acessar o locator para pegar a implementação, já no caso da DI isso não é necessário.

This message was edited 2 times. Last update was at 18/12/2007 11:27:00

IMO, acredito que DI pegou carona na popularidade do spring na época do embate forte com ejbs.

Mas quem pensa que para fazer testes unit´parios precisa de DI está completamente enganado, eu não estou usando DI apenas por restricoes besta do cliente, por mim usuaria..

Mas testes unitários... isso sim é indispensável.!

O fato é que muita coisa tem virado "modinha" ultimamente.

Tem gente que fala "usa DI e spring" ou "usa struts e MVC" sem saber do que está falando. Só repete o que viu nos fóruns por aí e não leva em consideração trade-offs de diversas tecnologias.

Para quem não viu que tinha um link no post da URL, acho que vale a pena ler o artigo original:
http://scruffylookingcatherder.com/archive/2007/08/07/dependency-injection.aspx

Onde o autor realmente defende bem a idéia. O que achei importante nisso tudo é que ele levanta o questionamento. Até onde DI vale a pena? O quanto devemos abrir mão das práticas de projeto que a DI nos tira? E, existem soluções ainda melhores que a DI?

Essas são perguntas que um programador prudente não pode deixar de fazer. E não só para DI, como para todas as tecnologias.

Não estou dizendo que DI é ruim, nem que tem que ser abandonado. Pelo contrário, ela tem se provado uma ótima alternativa, especialmente pq os processos ágeis tem como um dos seus pilares os testes unitários.

Só venho defendendo ha um bom tempo aqui que nós devemos saber exatamente os prós e os contras de cada solução. Fabricantes de frameworks vão tentar te convencer que os paradigmas que eles adotaram são a cura para todos os seus males. E isso nunca é verdade.

ViniGodoy wrote:
Só venho defendendo ha um bom tempo aqui que nós devemos saber exatamente os prós e os contras de cada solução. Fabricantes de frameworks vão tentar te convencer que os paradigmas que eles adotaram são a cura para todos os seus males. E isso nunca é verdade.

Claro, concordo com você. Avaliando o exemplo que tinha dado de statefull, já ouvi casos de empresas que tem que ficar reiniciando servidor de madrugada por causa da quantidade de objetos do contexto que ficam alocados (e perdidos) em memória.
O problema é que os conceitos já vem encapsulados dentro dos frameworks, pois a indústria quer facilitar. O preço da abstração é a dificuldade de saber o que está de baixo dos panos. Por isso sempre vai existir programador e usuário.

Blz. É uma boa a discussão que vocês estão tendo. E esse é um dos meus objetivos ao abrir esse tópico. Mas gostaria que os demais usuários do guj que usam DI colocasem para que a têm usado em seus projetos.

Isso enriquecerá mais ainda o tópico (e a mim também)

ViniGodoy wrote:Nós usamos para fazer aplicações orientadas a plugins (aqui falando mais de IoC)

O que quer dizer isso, de orientada a plugin?

Se a aplicação possuir ou necessitar de um modelo voltado a componentes acho válido a utilização de DI.

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Eai Pessoal,

Eu uso DI com o objetivo de obter um maior desacoplamento... agora o resultado disso é que ficou muito fácil pra criar mocks pros testes unitários, o que prova que código que segue as boas práticas de OO é fácil de testar

.

[]s
Ferry

BiraBoy wrote:

ViniGodoy wrote:Nós usamos para fazer aplicações orientadas a plugins (aqui falando mais de IoC)

O que quer dizer isso, de orientada a plugin?

Acho que ele estava se referindo a OSGI

fabeen wrote:Se a aplicação possuir ou necessitar de um modelo voltado a componentes acho válido a utilização de DI.

Modelo voltado a componentes? Isso me parece coisa de .NET....

rodrigoallemand wrote:

fabeen wrote:Se a aplicação possuir ou necessitar de um modelo voltado a componentes acho válido a utilização de DI.

Modelo voltado a componentes? Isso me parece coisa de .NET....

Componentes, Serviços, etc. Os nomes podem ser os mais variados. Mas a utilização do conceito não depende de plataforma.

http://martinfowler.com/articles/injection.html

Notícias, artigos e o maior fórum brasileiro sobre Java