Não obstante sua popularidade, há alguma evidência empírica que mostre que a Injeção de Dependência (e / ou o uso de um contêiner de DI) ajuda a, por exemplo, reduzir a contagem de bugs, melhorar a manutenção ou aumentar a velocidade de desenvolvimento em projetos de software da vida real?
18
Respostas:
TLDR
Os dados empíricos são irrelevantes. Ferramentas e práticas (como DI) resolvem problemas particulares . Entenda seus problemas, aprenda a usar as ferramentas e ficará óbvio quando uma ferramenta é valiosa - e você poderá explicar os resultados de maneira muito mais profética do que qualquer dado empírico generalizado, agregado.
E agora, com muito mais verbosidade ...
Existe evidência empírica?
Claro, provavelmente. Ou pelo menos talvez. Mas quem se importa? Não é relevante.
Uma análise estatística de custo-benefício da DI pode ser interessante academicamente, mas não necessariamente prevê o sucesso individual. Os resultados agregados ocultam sucessos e falhas individuais . E, eu poderia argumentar que dados sobre práticas "evangélicas" são particularmente venenosas. Essas disciplinas tendem a atrair fanáticos e tolos, os quais obscurecem o impacto líquido de uma implementação "pura" e qualquer um dos quais você poderia ser!
Então, como sabemos que a injeção de dependência é valiosa ?
Boa pergunta! Ótima pergunta, de fato. E estou com você - odeio perder tempo e esforço mental com as "melhores práticas" dogmáticas que ninguém pode justificar. Então, estou feliz que você perguntou.
Uhh Mas, aqui está o problema embaraçoso ... Em termos gerais , você não sabe. E, ainda mais embaraçoso, seu código pode não melhorar de forma alguma ao introduzir o DI.
SUSPIRO!
...
Então, talvez agora você esteja se perguntando ...
Por que eu deveria me preocupar com coisas que não foram provadas?
Primeiro de tudo, vamos todos - em todos os lados do debate - nos acalmar. Posso assegurar-lhe que entre o dogmatismo e o ceticismo existe um belo paraíso da razão e da empatia. (E o ocasional excêntrico SE.SE post.) E o POAP pode levá-lo até lá.
... Com o que quero dizer, o Princípio de Aplicação de Princípios :
(Eu diria "ênfase minha", mas é do meu próprio "blog" de qualquer maneira. Portanto, é todo meu!)
Deixe-me reiterar o ponto principal: você precisa entender por que está fazendo o que está fazendo.
E, talvez, para esclarecer, geralmente não faz sentido usar "algo" (como injeção de dependência) e usá-lo sem entender o problema que ele resolve - especificamente para você. Se você entender seus problemas e como o "algo" (como DI) funciona, será um pouco "óbvio" o quão útil é o "algo", muito independentemente do que os dados empíricos generalizados, agregados e sugeridos.
Se a ajuda ou a falta de ajuda de DI para você não é óbvia - ou pelo menos além de seus poderes de raciocínio - você não entende DI, ou não entende seus próprios problemas.
Vamos considerar uma "parábola" do mundo real.
Precisamos construir uma caixa. Nós temos madeira. Temos unhas. E temos duas ferramentas: um martelo de garra padrão e uma chave de fenda .
Agora, podemos ter alguns dados empíricos amplos para mostrar que as caixas construídas com chaves de fenda são caixas significativamente mais robustas em geral, em comparação com aquelas construídas com martelos. Mas, se você tentar aparafusar essas unhas, não terá uma caixa. E, se você tentar encaixá-los com a chave de fenda, poderá obtê-los; mas, exigirá muito mais tempo e esforço, e o resultado final será menos preciso (e robusto) do que você simplesmente usou o martelo.
E, se você já viu alguém usar uma dessas ferramentas antes e se entende como é uma caixa, a decisão é óbvia.
Telecinese!
Err ... hmm ...
Sim, então, que problema a Dependency Injection resolve?
Ele trabalha para evitar códigos rígidos e não configuráveis, que geralmente são, portanto, não testáveis .
Ele faz isso permitindo que o código de chamada decida com quais objetos um módulo opera. E sei que você está pensando e está certo: esse nem é um conceito remotamente novo. Os parâmetros de método / função existem desde que a álgebra aconteceu.
Começamos a evangelizar a passagem básica de parâmetros, chamando-a de "Injeção de Dependência", uma vez que acumulamos e herdamos código suficiente para ver nossos desequilíbrios. As montanhas de código em que estávamos sentados não podiam ser facilmente alteradas, testadas ou até reutilizadas , simplesmente porque as dependências estavam ocultas.
Portanto, a cruzada zelosa pela injeção de dependência ...
K. Mas posso passar argumentos muito bem. Por que os frameworks ?
Pelo que entendi, as estruturas de DI resolvem principalmente o problema de acúmulo de clichê (devido a DI, IMO excessivamente zeloso) - principalmente quando existem dependências "padrão" padrão para todos os módulos que precisam deles. As estruturas de DI fazem coisas mágicas (potencialmente até impertinentes!) Para inserir essas dependências padrão quando não são explicitamente transmitidas no ponto de invocação. (Mesmo efeito que um localizador de serviço quando usado dessa maneira, lembre-se!)
A injeção de dependência, como uma "disciplina", é realmente muito difícil de acertar. Não é uma questão de usar DI ou não; é uma questão de saber quais dependências provavelmente mudarão ou precisarão zombar e injetar essas dependências . E então, é questão de decidir se o DI se encaixa melhor do que alguma alternativa, como Localização do Serviço ...
Mas, eu encorajá-lo a Google-lo , talvez ver esta resposta SO , possivelmente falar com um desenvolvedor super-experiente e bem sucedido em sua indústria, e os exemplos posto específico para CR.SE .
fonte
Pesquisei no Google, Google Scholar, ACM e IEEE. Aqui estão os artigos que consegui encontrar:
Estruturas de injeção de dependência: uma melhoria na testabilidade? . Argumenta que "testabilidade" pode ser definida como "baixa coesão". Ele afirma que o DI leva a menor coesão, menor coesão está correlacionada com maior cobertura de teste e maior cobertura de teste está correlacionada com mais falhas encontradas. Diz que, com base nisso, o DI melhora a testabilidade.
Eu não gosto disso por alguns motivos. Antes de tudo, está dizendo "A está correlacionado com B, B está correlacionado com C, então A causa C", que é um par de etapas da lógica que não considero bem suportadas pelo artigo. Segundo, admite que está apenas medindo "subpartes de testabilidade", e que 'testabilidade' em geral não é algo facilmente definido. Finalmente, sua medida de testabilidade é definida em termos do número de dependências injetadas!
Efeitos da injeção de dependência na capacidade de manutenção . Eles comparam projetos usando DI a projetos que não usam DI encontrados no SourceForge e ver se há alguma diferença nas métricas de coesão. Para reduzir o viés, eles combinaram os projetos para serem o mais semelhante possível. Por fim, eles viram sinais de que projetos com muito DI estavam um pouco menos acoplados do que projetos com apenas um pouco de DI. No entanto, parece que não houve diferença significativa na coesão entre os projetos de DI e seu par não-DI, portanto, isso pode ser uma consequência de domínios específicos. Eles listam "nenhuma correlação" como resultado primário e o "talvez ajude um pouco?" como um tópico para um estudo mais aprofundado.
Avaliação empírica do impacto da injeção de dependência no desenvolvimento de aplicativos de serviço da web . O resumo não explica realmente o que eles estão procurando. Desenterrei e li uma pré-impressão e, até onde posso dizer, é realmente sobre o quão bem as ferramentas automatizadas podem descobrir serviços. Os serviços gravados no estilo DI foram descobertos com mais facilidade. Além disso, ele cita o estudo anterior que listei como fornecendo evidências empíricas de que o DI reduz o acoplamento, o que é o oposto do que esse artigo afirmava.
Para esses três artigos (e para Um estudo empírico sobre o uso de injeção de dependência em Java , que é apenas sobre detecção), acompanhei todos os artigos que os citaram, nenhum deles sobre a determinação da eficácia da DI. Diante de tudo isso, estou confiante em dizer que não , ainda não temos evidências empíricas sobre se a DI melhora ou não a qualidade do software.
fonte