¿Cómo se relaciona la inversión de control con la inversión de dependencia?

En muchos artículos en toda la web, los términos Inversión de control y Principio de inversión de dependencia parecen estar mezclados y utilizados como sinónimos (las herramientas llamadas "DI-Containers" y "IoC-Containers" confunden aún más la confusión). Un artículo de Wikipedia hace un buen trabajo tratando de explicar que IoC no es lo mismo que DI:

La inversión de control (IoC) describe un diseño en el que porciones personalizadas de un programa de computadora reciben el flujo de control de una biblioteca genérica y reutilizable

Entonces, DIP se trata de hacer que sus módulos dependan de abstracciones en lugar de implementaciones concretas.

Y IoC se trata de dar control sobre el flujo de su programa a un módulo separado. Y una de las cosas que puede hacer que este módulo haga es resolver las dependencias en tiempo de ejecución.

Esta diferencia parece justa, pero nunca he visto a nadie mencionar otras aplicaciones del principio de IoC que no sean la resolución de dependencias. La definición de Wikipedia es bastante amplia, y parece que podría hacer mucho más con un módulo que tiene que puede hacer llamadas a su código personalizado en función de su configuración y algo de lógica interna.

Entonces, aquí hay algunas preguntas que aún no puedo entender:

¿Cuál es la relación real entre IoC y DIP? ¿IoC siempre sirve como medio para implementar DIP?
¿Por qué las herramientas para la resolución de dependencias se denominan contenedores DI e IoC? Esto implica que DI e IoC son lo mismo.

Nota : Esta pregunta no es un duplicado de ¿Cuál es la diferencia entre DI e IoC , porque esta última pregunta sobre la inyección de dependencia, no la inversión de dependencia?

design-patterns inversion-of-control dependency-inversion

— Andre Borges
fuente

Posible duplicado de ¿Cuál es la diferencia entre DI y IoC?

— mosquito

@gnat, no, no lo es, mira mi edición

— Andre Borges

de acuerdo, me perdí eso lo siento

— mosquito

En mi opinión, la respuesta simple es "son lo mismo". IoC es otro nombre para la inversión de dependencia y ambos son una forma de lograr la inyección de dependencia. Veo "inversión de dependencia" como un término profundamente inútil ya que se confunde demasiado fácilmente con la inyección. Entonces, hay DI (inyección) e IoC es una forma de lograr la inversión de las dependencias / control a través de la inyección.

— David Arno

Hay un gran artículo en el sitio de Martin Fowler que tiene un capítulo específicamente sobre la diferencia entre DIP, DI e IoC . La esencia de esto (como se copió de ese sitio) es

DI trata sobre cómo un objeto adquiere una dependencia. Cuando se proporciona una dependencia externamente, el sistema está utilizando DI. IoC trata sobre quién inicia la llamada. Si su código inicia una llamada, no es IoC, si el contenedor / sistema / biblioteca vuelve a llamar al código que le proporcionó, es IoC.

DIP, por otro lado, se trata del nivel de abstracción en los mensajes enviados desde su código a la cosa que está llamando. Sin duda, el uso de DI o IoC con DIP tiende a ser más expresivo, poderoso y alineado con el dominio, pero se trata de diferentes dimensiones o fuerzas en un problema general. DI se trata de cableado, IoC se trata de dirección y DIP se trata de forma.

— JDT
fuente

IoC trata sobre quién inicia la llamada , ¿quién intima la llamada a qué? Si escribo ISomeInterface object = container.Resolve<ISomeInterface>()es eso IoC o no?

— Andre Borges

Lo que escribe es una implementación en el patrón del localizador de servicios. Esto también es IoC. No IoC es ISomeInterface object = new MyClass (). Entonces, la llamada que se entiende es la "llamada a la instanciación" (o quién llama 'nuevo').

— Sjoerd222888

"DIP, por otro lado, se trata del nivel de abstracción en los mensajes enviados desde su código a la cosa que está llamando". Eso me parece una tontería. ¿Dónde está la inversión en eso? Describe la abstracción de la dependencia, no la inversión.

— David Arno

@DavidArno, ¿estás diciendo que no podemos confiar en el sitio web de Martin Fowler?

— holdenmcgrohen

@holdenmcgrohen, son sus opiniones sobre las cosas. El hecho de que sea Martin Fowler no lo convierte en un hecho. Se equivoca a veces en la OMI, por ejemplo, con respecto al "modelo de datos de anemia". Otras veces, su muy perspicaz. En esta ocasión, creo que también está equivocado, ya que no tiene sentido.

— David Arno