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

42

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.

Timsworth
fuente
11
Son útiles para cambiar los errores al tiempo de ejecución en lugar del tiempo de compilación.
Den
1
@den ¿Por qué querríamos hacer eso? Eso parece violar fallar rápidamente
ESTE USUARIO NECESITA AYUDA

Respuestas:

26

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.

Jules
fuente
8
Darle al clavo en la cabeza. Nosotros no lo hacen los necesitamos. Simplemente hacen la vida más fácil para grandes proyectos. Honestamente, encuentro que los marcos son más complicados de lo que valen para proyectos más pequeños. Animaría a OP a no confundir la Inyección de dependencias con los marcos que lo admiten.
RubberDuck
1
bien dicho. ¿Y por qué reinventar la rueda cuando alguien más ha hecho una bonita y redonda?
Jwenting
Exactamente eso. Excepto que no necesito cambiar ningún código de instanciación , por supuesto, no hay código de instanciación ;-)
Mathieu Guindon
Simplemente parece que sus bibliotecas DI apestan. Los buenos pueden adivinar la clase para instanciar usando la reflexión.
Florian Margaine
2
cualquiera que use la reflexión para el procesamiento en tiempo de ejecución lo está haciendo mal. La reflexión es una de esas tecnologías que, solo porque puedes hacer algo no significa que debas hacerlo.
gbjbaanb
12
  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.

Thomas Junk
fuente
2
Puede usar bibliotecas DI sin usar un marco en absoluto.
Florian Margaine
5

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.

Mike Nakis
fuente
3
Mayormente de acuerdo, especialmente con el comentario XML. En mi humilde opinión, tener miedo de los constructores es probablemente una mala razón para usar un marco DI.
Robert Harvey
2
En mi humilde opinión, tener miedo de los constructores es una buena razón para mantenerse alejado de la programación. C -: =
Mike Nakis
55
Pero, ¿cómo es esto una ventaja sobre una fábrica (estática o no)? (Lo que tiene la ventaja de ser una opción que puede usar según corresponda, mientras que la primavera parece ser todo o nada injusto)
Richard Tingle
@RichardTingle Spring puede representar una ventaja principalmente debido a todas las otras cosas que hace además de DI, porque obviamente, puede lograr DI de muchas otras maneras, siendo las fábricas estáticas una. (Uno de los menos geniales, pero aún así). Pero la pregunta que se hace es si es necesario usar spring para lograr DI, y eso es lo que he estado tratando de responder: básicamente, no es necesario, solo es una conveniencia .
Mike Nakis
Este es un ejemplo de lo que DI no es. "TopLevel" no debe crear MiddleLevel, pero debe recibirlo cuando se construye TopLevelcomo un argumento para el constructor. Del mismo modo MiddleLeveldebería recibir un LowLevelen su constructor.
Más claro
1

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.

Paul J Abernathy
fuente
44
¿Podría explicar más sobre por qué es mejor definir qué clase concreta usar dentro de un xml en lugar de dentro de un archivo java? Eso es lo que nunca he entendido.
Richard Tingle
1
No es una bala mágica, pero una ventaja de usar archivos de configuración es que, al menos en teoría, son más fáciles de editar que el código. Además, un usuario que está ejecutando su programa puede cambiarlos pero no tiene acceso a su código fuente. En el ejemplo que di de mi crudo programa de inyección de dependencia, a veces cambiaba el archivo de configuración XML para poder cambiar la forma en que se ejecutaba el programa a pesar de que yo fui quien lo escribió. Si no necesita la configurabilidad externa, puede ser más fácil hacerlo con código. Tuve otro trabajo donde hicimos todo el DI en el código y funcionó bien.
Paul J Abernathy