¿Existe evidencia de que el uso de la inyección de dependencia mejora los resultados en la ingeniería de software?

A pesar de su popularidad, ¿hay alguna evidencia empírica que muestre que la Inyección de dependencias (y / o el uso de un contenedor DI) ayuda, por ejemplo, a reducir el conteo de errores, mejorar el mantenimiento o aumentar la velocidad de desarrollo en proyectos de software de la vida real?

TLDR

Los datos empíricos son irrelevantes. Las herramientas y prácticas (como DI) resuelven problemas particulares . Comprenda sus problemas, aprenda a usar las herramientas y se volverá obvio cuando una herramienta sea valiosa, y podrá explicar los resultados de manera mucho más profética que cualquier información empírica generalizada, agregada.

Y ahora, con mucha más verbosidad ...

¿Hay evidencia empírica?

Claro, probablemente. O al menos tal vez. ¿Pero a quién le importa? No es relevante

Un análisis estadístico de costo-beneficio de DI puede ser interesante académicamente, pero no necesariamente predice el éxito individual. Los resultados agregados ocultan los éxitos y fracasos individuales . Y, podría argumentar que los datos con respecto a las prácticas "evangélicas" son particularmente venenosos. ¡Estas disciplinas tienden a atraer tanto fanáticos como tontos, los cuales oscurecen el impacto neto de una implementación "pura", y cualquiera de los dos podría ser!

Entonces, ¿cómo sabemos que la inyección de dependencia es valiosa ?

¡Buena pregunta! GRAN pregunta, de hecho. Y estoy contigo: odio perder el tiempo y el esfuerzo mental en las "mejores prácticas" dogmáticas que nadie puede justificar. Entonces, me alegra que lo hayas preguntado.

Uhh Pero, aquí está el problema embarazoso ... En generales términos, que no sabe. Y, lo que es aún más vergonzoso, es posible que su código no mejore de ninguna manera al introducir DI.

¡JADEAR!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

Entonces, tal vez ahora te estés preguntando ...

¿Por qué debería molestarme en que las cosas no han sido probadas er nuthin '?

En primer lugar, establezcamos todos, en todos los lados del debate. Les puedo asegurar que entre el dogmatismo y el escepticismo se encuentra un hermoso paraíso de razón y sensatez. (Y la publicación excéntrica ocasional de SE.SE.) Y, el POAP puede guiarte allí.

... Con lo que quiero decir, el Principio de Aplicación de Principios :

Los principios, patrones y prácticas no son propósitos finales. Por lo tanto, la buena y adecuada aplicación de cada uno está inspirada y limitada por un propósito superior y más final.

¡Necesitas entender por qué estás haciendo lo que estás haciendo!

(El POAP no está exento del POAP).

^{(Yo diría, "énfasis mío", pero de todos modos es de mi propio "blog". ¡Así que todo es mío!)}

Permítanme reiterar el punto principal: necesita comprender por qué está haciendo lo que está haciendo.

Y tal vez para aclarar, por lo general no tiene sentido tomar un "algo" dado (como la inyección de dependencia), y usarlo sin comprender qué problema resuelve, específicamente para usted.Si comprende sus problemas y cómo funciona el "algo" (como DI), será algo "obvio" cuán útil es el "algo", en gran medida, independientemente de lo que sugieran los datos empíricos, agregados y generalizados.

Si amabilidad del DI o la ONU -helpfulness a que no es obvia - o al menos más allá de sus poderes de razonamiento - que o bien no entiende DI, o no entiende sus propios problemas.

Consideremos una "parábola" del mundo real.

Necesitamos construir una caja. Tenemos madera. Tenemos uñas Y tenemos dos herramientas: un martillo estándar y un destornillador .

Ahora, podemos tener algunos datos empíricos amplios para mostrar que las cajas construidas con destornilladores son cajas significativamente más robustas en general, en comparación con las construidas con martillos. Pero, si intentas atornillar esas uñas, no terminarás con una caja en absoluto. Y, si intentas golpearlos con el destornillador, eventualmente puedes meterlos; pero requerirá mucho más tiempo y esfuerzo, y el resultado final será menos preciso (y robusto) que si hubiera utilizado el martillo.

Y, si alguna vez has visto a alguien usar cualquiera de las herramientas antes, y si entiendes cómo se ve una caja, la decisión es obvia.

¡Telequinesia!

Err ... hmm ...

Sí, entonces, ¿qué problema resuelve la inyección de dependencia?

Funciona para evitar el código rígido, no configurable, que a menudo, por lo tanto, no se puede comprobar .

Para ello, permite invocar código para decidir con qué objetos opera un módulo. Y sé que lo estás pensando, y tienes razón: este ni siquiera es un concepto remotamente nuevo. Los parámetros de método / función han existido desde que sucedió el álgebra.

Comenzamos a evangelizar el paso de parámetros básicos, llamándolo "Inyección de dependencia", una vez que acumulamos y heredamos suficiente código para ver nuestros desequilibrios. Las montañas de código sobre las que estábamos sentados no podían cambiarse, probarse ni reutilizarse fácilmente , simplemente porque las dependencias estaban ocultas.

Por lo tanto, la celosa cruzada por la inyección de dependencia ...

K. Pero, puedo pasar argumentos muy bien. ¿Por qué los marcos ?

Según tengo entendido, los marcos DI resuelven principalmente el problema de la acumulación de repeticiones (debido a DI excesivo, IMO), particularmente cuando hay dependencias "predeterminadas" estándar para todos los módulos que los requieren. Los marcos DI hacen cosas mágicas (¡potencialmente incluso traviesas!) Para deslizar esas dependencias predeterminadas cuando no se pasan explícitamente en el punto de invocación. (¡El mismo efecto que un Localizador de servicios cuando se usa de esta manera, ten en cuenta!)

La inyección de dependencia, como una "disciplina", es realmente difícil de hacer bien. No se trata de usar DI o no; es una cuestión de saber qué dependencias son propensos al cambio o necesidad burla y la inyección de los . Y luego, es cuestión de decidir si la DI encaja mejor que alguna alternativa, como la ubicación del servicio ...

Pero, me animo a Google que , tal vez ver esta respuesta SO , posiblemente hablar con un desarrollador súper experimentado y exitoso en su industria, y después de los ejemplos específicos a CR.SE .

Busqué en Google, Google Scholar, ACM e IEEE. Aquí están los documentos que he podido encontrar:

• Marcos de inyección de dependencias: ¿una mejora en la capacidad de prueba? . Sostiene que la "capacidad de prueba" se puede definir como "baja cohesión". Establece que DI conduce a una cohesión más baja, la cohesión más baja se correlaciona con una mayor cobertura de prueba, y que una mayor cobertura de prueba se correlaciona con más fallas encontradas. Dice que, en base a esto, DI mejora la capacidad de prueba.

  No me gusta esto por un par de razones. En primer lugar, dice: "A está correlacionado con B, B está correlacionado con C, por lo que A causa C", que es un par de pasos en la lógica que no veo como bien respaldados por el documento. En segundo lugar, admite que solo mide "subpartes de comprobabilidad", y que la "comprobabilidad" en general no es algo fácil de definir. Finalmente, su medida de comprobabilidad se define en términos del número de dependencias inyectadas.

• Efectos de la inyección de dependencia en la mantenibilidad . Comparan proyectos que usan DI con proyectos que no usan DI que encontraron en SourceForge y ven si hay alguna diferencia en las métricas de cohesión. Para reducir el sesgo, combinaron los proyectos para que fueran lo más similares posible. Finalmente, vieron señales de que los proyectos con mucha DI estaban algo menos acoplados que los proyectos con solo una pequeña DI. Sin embargo, parece que no hubo una diferencia significativa en la cohesión entre los proyectos DI y su par no DI, por lo que podría ser una consecuencia de los dominios específicos. Enumeran "sin correlación" como su resultado principal y el "¿quizás ayuda un poco?" como tema para estudio adicional.

• Evaluación empírica del impacto de la inyección de dependencia en el desarrollo de aplicaciones de servicios web . El resumen realmente no explica lo que están buscando. Desenterré y leí una preimpresión y, por lo que puedo decir, en realidad se trata de qué tan bien las herramientas automatizadas pueden descubrir los servicios. Los servicios escritos en un estilo DI se descubrieron más fácilmente. Además, cita el estudio anterior que enumeré como que proporciona evidencia empírica de que la DI reduce el acoplamiento, que es lo contrario de lo que afirmaba ese documento.

Para estos tres artículos (y para Un estudio empírico sobre el uso de la inyección de dependencia en Java , que se trata solo de detección), realicé un seguimiento de todos los documentos que los citaron, ninguno de los cuales trataba de determinar la efectividad de la DI. Dado todo esto, confío en decir que no , todavía no tenemos evidencia empírica sobre si DI mejora o no la calidad del software.