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

Plugins são componentes feitos para serem acoplados a sua aplicação depois do código já compilado.

Eles precisam ser ainda mais desacoplados do que um modelo de componentes tradicional, pois não se sabe o que um terceiro, implementador do plugin, vai querer colocar por lá.

Ferryman wrote: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 .

Acho que é esse mesmo o questionamento do autor do artigo. Por que você usa DI e não outro padrão qualquer? Existem vários padrões (muitos deles mais simples) que geram desacoplamento (ele mesmo cita um exemplo com o provider no artigo).

Ou o motivo é só por causa dos testes unitários?

Eu vou admitir.
Um dos grandes motivos pelo qual eu uso DI são, exclusivamente, os testes unitários.
O outro é pq é conveniente. Como uso muito o spring, acabo usando DI pq o spring foi feito para trabalhar com ela.

Aliás, que bom que alguém citou o Fowler. Já notou que ele mesmo diz na descrição do padrão:

"Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

Está começando a melhorar. Pena que poucos aqui, como o Vini, estão postando sua experiência própria e a razão pela qual estão utilizando DI.

Quem utiliza DI, posta ae sua experiência vá lá

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

Correto! Concordo com vc... mas esse termo "Modelo de Componentes" é bastante utilizado pelo pessoal de .NET focados em orientação a eventos e os seus "maravilhosos" componentes e controllers por componente...

Eu pessoalmente não estou usando, muito por causa de restrições de ambiente e performance. Vi alguns amigos (arquitetos) pulando pra dentro do Spring (convencidos pela galera aqui do guj e pelo tio Rod) e alguns desses quebraram a cara, não no debug, mas no treinamento da galera que daria manutenção. IoC é um assunto muito extenso, a grande maioria dos desenvolvedores ainda nem sabe desenvolver bem com OO pura e simples, vixe maria!!!

Meus testes unitários são sacais, tá tudo muito amarrado, concordo que esses poderiam melhorar bastante só pelo fato de usar um framework IoC mas não acho que pro me caso isso justifique.

Que problemas de performance Dependency Injection tem te dado?

agodinhost wrote

Vi alguns amigos (arquitetos) pulando pra dentro do Spring (convencidos pela galera aqui do guj e pelo tio Rod)

Vc. vai ter que ser mais objetivo nesse "convencidos pela galera aqui do guj".???

mas no treinamento da galera que daria manutenção.

Então o problema foi outro.

pcalcado wrote:Que problemas de performance Dependency Injection tem te dado?

A aplicação que utilizei como base para a minha medição foi uma aplicação utilizando Spring com Hibernate. O pessoal que desenvolveu essa aplicação usou os templates do spring pra hibernate e tal mas eles não tinham grandes conhecimentos de hibernate SQL (IMO, seis meses atrás) - não sei se tinham pro Spring, não olhei o código à fundo. Sei que, dado o tempo que EU tinha pra avaliar o risco decidi por não por minha bunda na janela (fora o fato de não ter uma equipe com skill "real" pra dar manutenção IoC/Spring).

Concordo que minha afirmação inicial dá idéia, incorreta, de quê o problema de performance que mencionei era puramente do Spring (IoC), mas medi o que tinha em mãos na época. Antes de decidir por não utilizar percorri a web em busca de opiniões diversas e encontrei algumas reclamações de performance específicas pro Spring (principalmente para aquelas aplicações com grande números de classes injetadas). Não fui a fundo no assunto.

Para o meu caso, até agora, Spring não vai ajudar muito. Trabalho, hoje, numa fábrica onde a maioria do pessoal é júnior e quando o cara ganha algum skill novo ele acaba pulando fora para uma proposta melhor. Se eu optar por usar Spring nesse ambiente terei de adicionar no meu risco a provável incapacidade técnica tanto minha quanto da minha equipe, para, no tempo dado, levar esses projetos até o final.

Como disse antes: nossos testes de unidade são muito simples, amarrados, mas simples. Os de integração quase nem existem. Pode ser que, num futuro bem longe de onde estou hoje (empresa) eu use Spring da forma como ele merece - mas hoje ele não se justifica pra minha realidade.

Quanto à restrição de ambiente foi algo bem específico: nosso cliente (vale) simplesmente não "permite" a utilização de "frameworks" não homologados.

WilliamSilva wrote:Vc. vai ter que ser mais objetivo nesse "convencidos pela galera aqui do guj".???

Preciso mesmo? A galera aqui do guj defende o spring como se ele fosse a nona maravilha do mundo (a oitava agora é o cristo certo?)

WilliamSilva wrote:Então o problema foi outro.

Pra esse exemplo eu concordo, mas vc realmente acha que eu preciso de Spring pra todo tipo de aplicação?

This message was edited 1 time. Last update was at 18/12/2007 22:31:56

Minha visão disso é:

IoC = Inversão de Controle = ao invés de suas classes decidirem por si só quais implementações elas irão utilizar, isso é configurado num lugar central. O caso clássico são os DAOs ou Repositórios.

Todas as suas classes vão utilizar um userDAO (interface) e o container de IoC vai injetar a implementação que vc deseja em todas elas, por exemplo um OracleUserDAO. Se amanhã vc quiser trocar a implementação para DummyUserDAO, por exemplo para testes, vc pode muito facilmente e comodamente fazer isso, alterando apenas uma linha de código nas suas configurações.

AutoWiring = DAOs precisam de Connection, ou Session do Hibernate, ou DataSource, ou sei lá o que... É muito comodo vc definir em apenas um lugar que o que precisar de uma connection vai receber uma connection e pronto. O trabalho sujo de ligamento e injeção é o container/framework que faz isso pra vc.

IoC e Autowiring promovem um belo desacoplamento, facilitam a manutenção, evolução, separação de responsabilidades e promovem um melhor entendimento do sistema, ao meu ver. Não é algo ESSENCIAL/FUNDAMENTAL, mas é uma bela boa prática hoje em dia. Se o framework que vc está usando suporta IoC/DI/Autowiring, então seria bem recomendável que vc faça uso desses recursos.

Eu gostaria muito da experiência pessoal de todos, sobretudo os mais antigos daqui sobre em que contexto e com que objetivo utilizaram isso. Esse é o principal objetivo do tópico.

pcalcado, saoj, vcs não gostariam de falar da experiência de vocês?

Vini, entre outros, fez isso. Achei massa e tá enriquecendo muito.

DI existe pois Java é uma linguagem muito fraca quando o assunto é abstração. Não é possivel criar qualquer forma de abstração sobre tipos, tão pouco é possivel criar sistemas realmente paramétricos. Não existe real motivo para não usar new diretamente, o problema é que não existe uma construção de instanciação paramétrica, e tão pouco existe o conceito real modulos, só existem namespaces.

Linguagens como NewSpeak permitem construção de modulos paramétricos os quais podem ser instanciados com suas dependencias informadas. É simples e intuitivo, módulos não são permitidos terem dependencias externas fixas, todas tevem ser paramétricas.

DI é apenas uma gambiarra para resolver mais um dos problemas de uma linguagem pobre.

This message was edited 2 times. Last update was at 19/12/2007 00:31:40

agodinhost wrote
Pra esse exemplo eu concordo, mas vc realmente acha que eu preciso de Spring pra todo tipo de aplicação?

Não, há outros recursos e digo o mesmo para o hibernate. Agora uma coisa é certa, há muita gente da área de TI usando ferramentas, frameworks etc. pela frequencia com que os assuntos são gerados pelos foruns. Alguns em sua maioria nem sabem se a ferramenta é adequada ao projeto, mais vc. colocou alguns pontos interessantes que devem ser reavaliados em um projeto.
sds.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Já no início, programadores ouvem que é uma boa prática desenvolverem para interfaces... "abstração" é a palavra da ordem (o sistema "pode" mudar de implementação em determinado serviço, mudar de frameworks e etc ).

O próximo passo é como abstrair: o coração disso...."Factories".

Então, com embasamento e as "motivações" propostas pelos gurus dos Design Patterns (gambiarras catalogadas para suprir deficiências semânticas ou de paradigmas), surgem os mais diversos nomes e códigos para garantir que seu sistema saia o mais burocrático, extensível e "abstrato" do mundo.

Então você vaga pela internet, encontra um Portal de malucos falando sobre Injeção de Dependência e resolve ler um pouco mais a respeito:

"Hey, mas peraê, ca-ca-ca-cadê os sssingletons nas classes de vocês? Suas AbstractFactories e seus respectivos produtos-fábricas? Onde vocês estâo gerenciando/instanciado estas interfaces? Vocês não precisam se preocupar com nada disso, tão de sacanagem comigo? E ainda por cima isso facilita o desenvolvimento seus Testes Unitários?"

É, eu acho DIP uma boa ...

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