Excelente explicación de la inyección de dependencia (inversión de control)

He leído muchas explicaciones sobre la inyección de dependencia o DI (anteriormente conocida como inversión de control) y el principio de Hollywood asociado ("No nos llames, te llamaremos"). Todos tienden a ser confusos, ya sea porque profundizan de inmediato en explicaciones muy detalladas o porque vinculan la explicación específicamente a una tecnología en particular. De tal manera que se pierde el patrón o se pierde su simplicidad. Aquí está la explicación más clara que he encontrado, ligeramente editada por brevedad (del muy buen Spring in Action, 2da. Ed. De Craig Walls):

"Cualquier aplicación no trivial se compone de dos o más clases que colaboran entre sí para realizar alguna lógica de negocio. Tradicionalmente, cada objeto es responsable de obtener sus propias referencias a los objetos con los que colabora (sus dependencias). Al aplicar DI, el los objetos reciben sus dependencias en el momento de su creación por alguna entidad externa que coordina cada objeto en el sistema. En otras palabras, las dependencias se inyectan en los objetos ".

Eso lo encuentro muy claro.

Inyección de dependencia se llamó originalmente Inversión de control (IoC) porque la secuencia de control normal sería que el objeto busca los objetos de los que depende por sí mismo y luego los llama. Aquí, esto se invierte: las dependencias se entregan al objeto cuando se crea. Esto también ilustra el principio de Hollywood en funcionamiento: no llame a sus dependencias, se las daremos cuando las necesitemos.

Si no usa DI, probablemente se esté preguntando por qué es tan importante. Ofrece una ventaja clave: acoplamiento suelto. Los objetos se pueden agregar y probar independientemente de otros objetos, porque no dependen de nada más que de lo que les pasa. Cuando se utilizan dependencias tradicionales, para probar un objeto, debe crear un entorno en el que existan todas sus dependencias y sean accesibles antes de poder probarlo. Con DI, es posible probar el objeto de forma aislada pasándole objetos simulados para los que no desea o necesita crear. Del mismo modo, la adición de una clase a un proyecto se facilita porque la clase es autónoma, por lo que se evita la "gran bola de pelo" en la que suelen evolucionar los grandes proyectos.

El desafío de DI es escribir una aplicación completa usándolo. Algunas clases no son un gran problema, pero una aplicación completa es mucho más difícil. Para aplicaciones completas, con frecuencia desea un marco para administrar las dependencias y las interacciones entre objetos. Los marcos de DI a menudo son impulsados ​​por archivos XML que ayudan a especificar qué pasar a quién y cuándo. Spring es un marco Java DI de servicio completo; Otros marcos de DI más ligeros incluyen NanoContainer y el PicoContainer aún más ligero.

La mayoría de estos marcos tienen buenos tutoriales para ayudar a los principiantes a encontrar el camino.

Esta historia, "Excelente explicación de la inyección de dependencia (inversión de control)" fue publicada originalmente por JavaWorld.