Por qué son innecesarios los contenedores IOC con lenguajes dinámicos

IoC proporciona un mecanismo para romper el acoplamiento que se obtiene cuando un objeto llama a 'new' en otra clase. Este acoplamiento une el objeto invocador con la implementación instanciada de cualquier interfaz que implemente.

En lenguajes estáticos cuando se hace referencia a una clase por nombre (para llamar a new en ella), no hay ambigüedad. Este es un acoplamiento apretado a una clase específica.

En lenguajes dinámicos llamar a new X es un marcador de posición para " instanciar cualquier clase que se defina como X en el punto de ejecución". Este es un acoplamiento más suelto, ya que solo está acoplado al nombre X.

Esta sutil diferencia significa que en un lenguaje dinámico normalmente se puede cambiar lo que es X, por lo que la decisión sobre qué clase se instanciará es todavía modificable fuera de la clase que llama.

Sin embargo, personalmente encuentro que hay dos ventajas para IoC que no obtengo al confiar en el lenguaje dinámico para permitir la inyección.

Uno de los efectos secundarios de pasar dependencias a través de constructores es que terminas con clases "building block" que son muy desacopladas, reutilizables y fáciles de probar. No tienen idea de en qué contexto están destinados a ser utilizados, por lo que puede reutilizarlos en todo el lugar.

El otro resultado es tener código explícito para hacer el cableado. Hecho correctamente esto representa limpiamente la estructura de su aplicación y su descomposición en subsistemas y ciclos de vida. Esto hace que la gente decida explícitamente qué ciclo de vida o subsistema con el que quieren asociar su clase (al escribir el código wiring), y se concentran en el comportamiento del objeto al escribir la clase.

Como dijo Jörg W Mittag.. "Esas herramientas son innecesarias, los principios de diseño no lo son." Creo que son innecesarias, pero hechas bien, aún valiosas.