¿Cómo aumenta la inyección de dependencia el acoplamiento?

32

En la página de Wikipedia sobre inyección de dependencias, la sección de desventajas nos dice esto:

La inyección de dependencia aumenta el acoplamiento al requerir que el usuario de un subsistema satisfaga las necesidades de ese subsistema.

con un enlace a un artículo contra la inyección de dependencia .

La inyección de dependencia hace que una clase use la interfaz en lugar de la implementación concreta. Eso debería resultar en una disminución del acoplamiento , ¿no?

¿Qué me estoy perdiendo? ¿Cómo aumenta la inyección de dependencia el acoplamiento entre clases?

dependency-injection coupling

— BЈовић
fuente

2

No estoy seguro de quién escribió esa lista de desventajas, pero lo tomaría con un grano de sal. Por ejemplo, he visto que DI reduce el tamaño de una base de código en 2/3 al eliminar una tonelada de código de configuración redundante.

— Rob

@RobY Utilicé principalmente la fábrica para inyectar la dependencia, y mi experiencia es que aumenta el tamaño del código, pero simplifica las pruebas.

— B 4овић

Intente utilizar una alternativa como Registro o Contexto Pasando;) O bien, código que simplemente crea instancias de objetos y luego extrae sus propiedades de la configuración. Principalmente, estoy hablando de la diferencia entre ahora y hace 15 años.

— Rob

Relacionado: stackoverflow.com/a/9503612/264697 . La respuesta de Mark Seemann explica cómo se reduce el acoplamiento general mediante la inyección de dependencia.

— Steven

42

Entonces, ¿qué me estoy perdiendo?

La inyección de dependencia disminuye el acoplamiento entre una clase y su dependencia. Pero aumenta el acoplamiento entre una clase y su consumidor (ya que el consumidor necesita más información para crearlo) y la dependencia y su consumidor (ya que el consumidor necesita saber la dependencia a utilizar).

Muy a menudo, esta es una buena compensación. La clase no debería conocer los detalles sobre sus dependencias más allá de una interfaz, y debería ser responsabilidad de la aplicación vincular bits específicos de código.

— Telastyn
fuente

Correcto, el acoplamiento disminuye de una manera y aumenta de otra.

— Paul Draper

Pero el consumidor no lo crea; ese es más bien el punto.

— Casey

@emodendroket - ¿Eh? La inversión de control permite al consumidor no crearlo. La inyección de dependencia es ortogonal a eso.

— Telastyn

Bueno, estás haciendo una distinción con la que no estoy familiarizado, ya que generalmente los términos se usan indistintamente.

— Casey

22

Supongamos que tiene un subsistema Sque depende de una conexión de base de datos D. Sin inyección de dependencia, existe un acoplamiento relativamente estrecho entre Sy D, porque Snecesita saber cómo usarlo Dy cómo crearlo. El resto del sistema, sin embargo, puede ser felizmente inconsciente de esta dependencia entre Sy D.

Con la inyección de dependencia, el acoplamiento entre Sy se Dvuelve más flojo, porque elimina del Sconocimiento cómo crear un D. Ssolo necesita saber cómo usarlo. El mayor acoplamiento general proviene del hecho de que otras partes del sistema ahora necesitan saber Dy posiblemente cómo crear uno. El alcance de este aumento en el acoplamiento depende de cómo Dse inyecte la dependencia en S:

Con la inyección del constructor, el creador de Snecesita una dependencia Dy posiblemente el conocimiento de cómo crear una.
Con la inyección a nivel de método , cada persona que llama de un método a Stravés del cual Dse inyecta necesita una dependencia Dy posiblemente el conocimiento de cómo crear uno.

En cualquier caso, el número de clases que depende de los Daumentos y el conocimiento de cómo crear un Dtodavía debe estar presente en algún lugar del sistema. Esto crea un aumento general del acoplamiento.

— Bart van Ingen Schenau
fuente

Ok, tiene sentido para la inyección del constructor y del setter. Pero si uno usa el patrón de fábrica o de estrategia, la creación se mueve allí, y la clase solo usa el objeto inyectado. ¿O no es una inyección de dependencia (solo inversión de control)?

— BЈовић

Incluso con la inyección de fábrica, el creador de Snecesidades debe suministrar una fábrica de D, lo que significa que necesita saber qué Susos D(o al menos alguna interfaz de la misma).

— Idan Arye

7

Estoy totalmente en desacuerdo con que aumenta el acoplamiento.

Sin inyección de dependencia, tiene un acoplamiento estrecho entre un subsistema y la implementación concreta de la dependencia.

Con la inyección de dependencia ha desacoplado el subsistema de la implementación de la dependencia.

Hacer el argumento de que aumenta el acoplamiento entre el consumidor y este subsistema es MUY cuestionable, ya que implica que el consumidor ahora está estrechamente vinculado a la dependencia requerida por el subsistema. Todo lo que significa es que está escribiendo un código estrechamente acoplado que une a su consumidor con la dependencia. Idealmente TODO su código está desacoplado.

Inyección de constructor:

La resolución de dependencia es manejada por un contenedor de inyección de dependencia o una fábrica. El consumidor puede obtener una implementación concreta del subsistema desde el contenedor de inyección de dependencia o una fábrica.

El consumidor no necesita saber cómo se ve el constructor del subsistema. No hay acoplamiento a la dependencia del subsistema.

Método de inyección:

Lo mismo que la inyección del constructor, excepto que ahora el consumidor necesita obtener una instancia concreta de la dependencia del contenedor o la fábrica (o incluso hacer que se inyecte el método / constructor) e inyectarlo en el método. Nuevamente, el consumidor no está acoplado a una implementación concreta de la dependencia.

TL; DR El peor caso para la inyección de dependencia en un subsistema es que el acoplamiento se cambia al código del consumidor. NO HAY UN INCREMENTO TOTAL EN EL ACOPLAMIENTO.

El mejor de los casos es que todos los sistemas ahora están acoplados libremente y la inyección de dependencia se controla a través de contenedores o fábricas de inyección de dependencia.

— Halcón
fuente