Por que precisamos de frameworks para injeção de dependência? [fechadas]

38

Eu tenho lido mais sobre o princípio de Inversão de Controle e Injeção de Dependência como uma implementação e tenho certeza que entendi.

Parece estar dizendo basicamente 'não declarar as instanciações de seus alunos dentro da classe'. Em vez disso, as instanciações devem ser passadas e atribuídas através do construtor; 'injetado' na classe de uma fonte externa.

Se é tão simples, o que parece ser, por que precisamos de frameworks como spring ou guice que implementam isso com anotações? Estou faltando algo fundamental aqui? Estou realmente lutando para entender o que é o uso de estruturas de injeção de dependência.

Edit: Sobre o possível duplicado, acredito que minha pergunta é mais original, já que está perguntando sobre estruturas de DI em geral, não apenas sobre Spring. A primavera não é apenas uma estrutura de DI, então há muitas razões para alguém querer usar o Spring que não esteja relacionado à DI.

    
por timsworth 17.10.2015 / 21:12
fonte

4 respostas

25

Nós não precisamos dos frameworks. É totalmente possível implementar a injeção de dependência manualmente, mesmo para um projeto relativamente grande.

Por outro lado, o uso de uma estrutura torna mais fácil, especialmente uma baseada em anotações ou detecção automática de dependências, pois simplifica o processo: se eu decidir que preciso de uma nova dependência em uma classe, tudo o que preciso do é adicioná-lo ao construtor (ou declarar um setter) e o objeto é injetado - não preciso alterar nenhum código de instanciação.

Além disso, as estruturas geralmente contêm outras funcionalidades úteis. O Spring, por exemplo, contém uma estrutura útil para programação orientada a aspectos, incluindo demarcação de transação declarativa (que é extremamente útil) e uma variedade de implementações de adaptadores que facilitam a integração de muitas bibliotecas de terceiros.

    
por 17.10.2015 / 21:40
fonte
11
  1. Por que precisamos de DI (Injeção de Dependência)?

    O mecanismo DI separa a produção de objetos do consumo de objetos. As dependências de que um objeto precisa são entregues transparentemente do lado de fora. A vantagem do mecanismo é clara: você pode trocar dependências a qualquer momento, por exemplo, usando um Objeto Nulo para fins de teste.

  2. Como isso é feito?

    Existem várias maneiras de atingir o objetivo:

    • Injetando dependências via injeção de construtor
    • Injeção via getter / setter
    • Injeção de interface
  3. Precisamos de estruturas de DI?

    Não. De modo nenhum. Você poderia simplesmente passar todas as instâncias para outros objetos manualmente. Se você tiver um pequeno aplicativo, não há necessidade de um contêiner de mola.

    Mas, por outro lado, os frameworks ajudam você, gerenciando objetos:

    • Eles ajudam você a conectar relações complexas de objetos. Você não tem que escrever código clichê para gerar instâncias e passá-las para os objetos apropriados

    • Eles ajudam você a controlar quando um objeto é criado: você pode criar instâncias durante o bootstrapping do aplicativo, mas em alguns casos uma criação lenta - somente quando necessário - é melhor

    • Eles ajudam você a controlar quantas instâncias são criadas: uma por tempo de vida do aplicativo ou uma por solicitação (caso você esteja fazendo programação na web)

Se você projetar tem um tamanho apropriado - se você sente a necessidade de escrever menos código clichê - faz todo o sentido usar um framework (DI-). Existem mais prós do que contras.

    
por 18.10.2015 / 01:08
fonte
5

Com a primavera, é principalmente uma questão de conveniência.

Se você tiver a classe TopLevel , que constrói a classe MiddleLevel , que constrói a classe LowLevel , e você percebe que precisa de um novo parâmetro de construtor em LowLevel , também precisa adicioná-la a TopLevel e para MiddleLevel , simplesmente para que, quando chegar a hora de MiddleLevel construir um LowLevel , o valor esteja disponível para que possa ser passado para seu construtor. Com a primavera, basta adicionar uma anotação.

Além disso, com a mola, é possível definir as dependências em um arquivo de configuração externa em vez de xml, e isso supostamente lhe dá a capacidade de gerar um novo sistema com uma fiação totalmente diferente "sem alterar qualquer código". (IMHO isso é completamente mal direcionado, porque alterar o xml não é muito diferente de alterar o código e, na verdade, o código geralmente tem uma verificação de erros e uma verificação de tipos muito melhores do que o xml).

Outra coisa é que muitas pessoas têm medo de construtores; eles não os entendem, não gostam deles, preferem não usá-los.

    
por 17.10.2015 / 21:36
fonte
1

Há alguns anos, escrevi um programa para monitorar páginas da Web, portlets da Web e até mesmo determinadas tabelas de banco de dados em uma empresa onde eu trabalhava. Eu queria que fosse flexível o suficiente para que o usuário pudesse especificar quais monitores seriam executados e com quais parâmetros (urls, logins, critérios de sucesso, etc.). Então, eu o escrevi para ler de um arquivo XML e usar a reflexão Java para instanciar as classes especificadas e usar os métodos setter para definir os parâmetros especificados.

Mais tarde, descobri que a Spring fará o mesmo por você e muito mais.

Então, no meu caso, descobri que

  1. O uso de uma estrutura de injeção de dependência ajuda a tornar o programa flexível e facilita a especificação de como ele funcionará (dentro de parâmetros bem definidos, é claro).

  2. Usar uma estrutura de terceiros impede que você tenha que reinventar a roda.

por 19.10.2015 / 14:41
fonte