¿Por qué necesitamos marcos para la inyección de dependencia? [cerrado]

He estado leyendo más sobre el principio de Inversión de control y la Inyección de dependencias como una implementación del mismo y estoy bastante seguro de que lo entiendo.

Parece estar básicamente diciendo 'no declares las instancias de los miembros de tu clase dentro de la clase'. Más bien que las instancias deberían pasarse y asignarse a través del constructor; 'inyectado' en la clase desde una fuente externa.

Si es así de simple, lo que parece ser, ¿por qué necesitamos marcos como spring o guice que implementen esto con anotaciones? ¿Me estoy perdiendo algo fundamental aquí? Realmente estoy luchando por comprender cuál es el uso de los marcos de inyección de dependencia.

Editar: sobre el posible duplicado, creo que mi pregunta es más única, ya que se trata de marcos DI en general, no solo Spring. Spring no es solo un marco DI, por lo que hay muchas razones por las que alguien querría usar Spring que no estén relacionadas con DI.

No necesitamos los marcos. Es completamente posible implementar la inyección de dependencia manualmente, incluso para un proyecto relativamente grande.

Por otro lado, usar un marco lo hace más fácil, particularmente uno basado en anotaciones o detección automática de dependencias, ya que simplifica el proceso: si decido que necesito una nueva dependencia en una clase, todo lo que tengo que hacer es agregar para el constructor (o declarar un setter) y el objeto se inyecta, no necesito cambiar ningún código de instanciación.

Además, los marcos a menudo contienen otra funcionalidad útil. Spring, por ejemplo, contiene un marco útil para la programación orientada a aspectos, incluida la demarcación de transacciones declarativas (que es extremadamente útil) y una variedad de implementaciones de adaptadores que hacen que muchas bibliotecas de terceros sean más fáciles de integrar.

1. ¿Por qué necesitamos DI (inyección de dependencia)?

   El mecanismo DI separa la producción de objetos del consumo de objetos. Las dependencias que necesita un objeto se entregan de forma transparente desde el exterior. La ventaja del mecanismo es clara: en cualquier momento puede intercambiar dependencias, por ejemplo, usar un objeto nulo para fines de prueba.

2. Como se hace

   Hay varias formas de lograr el objetivo:

   • Inyección de dependencias mediante inyección de constructor
   • Inyección a través de getter / setter
   • Inyección de interfaz

3. ¿Necesitamos marcos DI?

   No, en absoluto. Simplemente puede pasar todas las instancias a otros objetos manualmente. Si tiene una aplicación pequeña, no es necesario un contenedor de resorte.

   Pero, por otro lado, los marcos te ayudan, administrando objetos:

   • Le ayudan a conectar relaciones complejas de objetos. No debe escribir ningún código repetitivo para generar instancias y pasarlas a los objetos apropiados.

   • Le ayudan a controlar cuándo se crea un objeto: puede crear instancias durante el arranque de la aplicación, pero en algunos casos es mejor una creación diferida, solo cuando sea necesario.

   • Le ayudan a controlar cuántas instancias se crean: una por vida útil de la aplicación o una por solicitud (en caso de que esté haciendo programación web)

Si el proyecto tiene un tamaño apropiado, si siente la necesidad de escribir menos código repetitivo, tiene sentido usar un marco (DI-). Hay más ventajas que desventajas.

Con la primavera, es principalmente una cuestión de conveniencia.

Si tiene una clase TopLevelque es una clase de construcción MiddleLevelque construye una clase LowLevel, y se da cuenta de que necesita un nuevo parámetro de constructor LowLevel, también debe agregarlo a TopLevel, y MiddleLevelsimplemente, para que cuando sea el momento de MiddleLevelconstruir un LowLevelvalor esté disponible para que pueda pasar a su constructor. Con spring, solo agrega una anotación.

Además, con spring, es posible definir las dependencias en un archivo de configuración externo en lugar de xml, y esto supuestamente le brinda la capacidad de generar un nuevo sistema con un cableado completamente diferente "sin cambiar ningún código". (En mi humilde opinión, esto está completamente mal dirigido, porque alterar xml no es muy diferente de alterar el código, y en realidad, el código generalmente tiene una verificación de errores y una verificación de tipo mucho mejores que xml).

Otra cosa es que muchas personas tienen miedo de los constructores; no los entienden, no les gustan, prefieren no usarlos.

Hace unos años escribí un programa para monitorear páginas web, portlets web, incluso ciertas tablas de bases de datos, en una compañía para la que solía trabajar. Quería que fuera lo suficientemente flexible como para que el usuario pudiera especificar qué monitores se ejecutarían y con qué parámetros (URL, inicios de sesión, criterios de éxito, etc.). Así que lo escribí para leer desde un archivo XML y usar la reflexión de Java para crear instancias de las clases especificadas y usar métodos de establecimiento para establecer los parámetros especificados.

Más tarde descubrí que Spring hará lo mismo por ti y mucho más.

Entonces en mi caso encontré que

1. El uso de un marco de inyección de dependencias ayuda a que el programa sea flexible y facilita la especificación de cómo funcionará (dentro de parámetros bien definidos, por supuesto).

2. El uso de un marco DI de terceros evita que tenga que reinventar la rueda.