Também não dá para esquecer do aumento de complexidade, Louds…
Você já viu alguns programas em C++ onde o sujeito faz o seguinte?
(Adaptando para sintaxe java-like)
class Foo<T> extends T {
public void bla() { T.doBlah(); }
}
Código genérico é complexo. Difícil de manter, difícil de debugar.
E não estou falando só do C++.
É difícil gerenciar tanta abstração e, embora em muitos casos as soluções sejam realmente elegantes, não adianta você ter um time em que o menos capacitado deva ter pelo menos uns 6 ou 8 anos de experiência.
Só para acrescentar, o Spring instrumenta o código à partir da cglib que é muito mais rápido que reflexão. Alguns preocupados com performance, chegaram a compará-lo com o Guice do Google e em sua nova versão, 2.5 , segundo a documentação oficial, está 200% mais rápido que seu concorrente.
[quote=ViniGodoy]Também não dá para esquecer do aumento de complexidade, Louds…
Você já viu alguns programas em C++ onde o sujeito faz o seguinte?
(Adaptando para sintaxe java-like)
class Foo<T> extends T {
public void bla() { T.doBlah(); }
}
Código genérico é complexo. Difícil de manter, difícil de debugar.
E não estou falando só do C++.
É difícil gerenciar tanta abstração e, embora em muitos casos as soluções sejam realmente elegantes, não adianta você ter um time em que o menos capacitado deva ter pelo menos uns 6 ou 8 anos de experiência.[/quote]
Evita muito trabalho de reflexão, por exemplo para construir engines. Costumo muito usar generics para criar camadas versáteis, escrevendo uma única vez.
[quote=pcalcado][quote=louds]
Módulos instanciaveis não se restringe apenas a DI da mesma maneira que generics (generics de verdade, assim como no C#) não se restringe apenas a collections. Quanto aos problemas de configuração, sistemas enormes provavelmente terão um problema semelhante quanto ao tamanho da cola com ambas as técnicas.
DI é uma necessidade quando não é possivel abstrair sobre tipos, simples assim.
[/quote]
Tá, mas falando de DI (que é o tema aqui).
Ok, então o problema não é específico de Java (ou C# ou C++ ou demais linguagens na linha de clonagem) e sim de todo um grupo extenso de possivelmente inclui Lisp, Smalltalk e Scala, certo? Se eu estiver certo comentaria que haver uma solução melor é ótimo mas não faz necessariamente da atual uma coisa ruim. Não é porque uma coisa é melhor que a outra é ruim.[/quote]
Com Smalltalk é possivel criar algo bem próximo a módulos instanciaveis, isso se deve ao fato de ser uma linguagem baseada em troca de mensagens. Scala permite trait types e higher order parametric polymorphism, precisaria pensar em um bom exemplo, mas com Scala é possivel ter todos beneficios de DI sem ter um framework. Uma boa utilidade disso, por exemplo, é quando vc quer testar um tipo e precisa instanciá-lo com mocks ou stubs como dependencias. Usando um framework de DI esse processo é meio chato, se não precisa de DI, fica natural.
Não entendi, java também é baseada em troca de mensagens.
[quote=louds]
Scala permite trait types e higher order parametric polymorphism, precisaria pensar em um bom exemplo, mas com Scala é possivel ter todos beneficios de DI sem ter um framework. Uma boa utilidade disso, por exemplo, é quando vc quer testar um tipo e precisa instanciá-lo com mocks ou stubs como dependencias. Usando um framework de DI esse processo é meio chato, se não precisa de DI, fica natural. [/quote]
Interessante, tem alguma referência? A única cisa relevate que achei no Google é meio contra isso:
Eu tenho impressão que você está jogando o bebê com a água suja mas devo estar errado.
O meu atual projeto usa DI e os seguintes pontos foram considerados:
Alternativa de desacoplamento entre cliente e servicos (actions vs servicos, servicos vs entidades, entidades vs daos)
Facilitação dos testes unitarios e de integração
No caso de decidir pelo spring:
Fácil acesso a documentacao
Boa integracao com outros frameworks utilizados
Trabalhar somente com servlet containers (no caso o tomcat)
Maior gama de recursos (controle de transacoes orientados a aspectos, internacionalizacao, testes de integracao com acesso ao banco de dados, unitarios com mocks, entre outras)
eu gosto de IoC/DI e sempre que possível, utilizo, ainda mais que geralmente meus modelos de domínio são anêmicos (ou seja: não existe entidades/domínicos ricos)
motivos que os utilizo
maior facilidade para controle de ciclo de vida dos beans
facilidade de implementação de transações/logging com AOP declarativo
consegue retirar uma boa parte de código comum, por exemplo, ficar dando new e set
tranquilidade no que se diz respeito a integração com outras coisas, por exemplo, não preciso ficar dando lookup em datasource sendo que posso configurar nele
se precisar alterar alguma coisa na criação de um bean, não preciso recompilar a classe desde que a alteração não seja de código, mas posso, por exemplo, utilizar um construtor X em vez do Y sem precisar recompilar a aplicação
posso integrar com struts, jsf, jpa e afins. Fácil manutenção
