¿Alguna necesidad de inyección de dependencia en Dynamic Languages?

Question

Para escribir el código de C# comprobable, uso DI en gran medida.

Sin embargo, últimamente he estado jugando con IronPython y he descubierto que, como puede burlarse de cualquier método/clase/función, etc ... que desee, la necesidad de DI ha desaparecido.

¿Es este el caso de langagues dinámicos como Python?

En lugar de:

class Person(Address) { 
... 

Puede tener:

class Person() { 
... 
    // Address initialised in here. 

para lenguajes dinámicos y por lo tanto después de DI manaual para langagues dinámicas, simplemente no es necesario.

¿Algún consejo sobre esto?

Answer 1

Dependency Injection también se trata de cómo unir las cosas juntas, lo que no tiene nada que ver con la simulación de objetos dependientes. Hay una diferencia entre tener un -instance Foo que necesita una Bar -conexión de algún tipo instanciarlo directamente y hacer que se ignoran por completo cómo se obtiene esa conexión con tal de que tiene ella.

Si usa la inyección de dependencia, también obtendrá una mejor comprobabilidad. Pero lo contrario no es verdad. Una capacidad de prueba más sencilla al poder sobrescribir cualquier cosa no aporta las otras ventajas de la inyección de dependencia. Hay muchos componentes/marcos DI para Python disponibles exactamente por estos motivos.

Answer 2

Creo que estás presentando una pregunta que parece ser sobre las mejores prácticas, pero en realidad se trata del rendimiento en tiempo de ejecución.

Deshágase de la inyección de dependencia? ¿Cómo puede un administrador de versiones de software dormir por la noche?

Las pruebas de la función a realizar seguramente deben ralentizar el programa una o dos páginas.

// my generic function entry point - IronPython 
if func="a": 
    ... 
if func="b": 
    ... 
if func="c": 
    ... 

Puede usar Python estándar con clases ... o puede asignar punteros a funciones para que funcionen como miembros del puntero. ¿Qué clase de bestia es ...? Sé que sé. Python, creo que es difícil de definir, pero me gusta. Y me gusta y pienso mucho en la inyección de dependencia, no es que haya tenido mucho tiempo para pensar en asignarle un nombre tan largo a la práctica.

Answer 3

Estoy totalmente en desacuerdo con su afirmación de que la Inyección de Dependencia no es necesaria en los lenguajes de tipado dinámico. Las razones por las que DI es útil y necesario son completamente independientes de la disciplina de tipeo del lenguaje.

La principal diferencia es que DI en lenguajes de tipado dinámico es fácil y sin complicaciones: no necesita un marco de trabajo pesado y un sinfín de líneas de configuración XML.

En Ruby, por ejemplo, solo hay dos marcos DI. Ambos fueron escritos por un programador de Java. Ninguno de los dos marcos es utilizado por un proyecto solo. Ni siquiera por el autor de esos marcos.

Sin embargo, DI se utiliza en todo el lugar en Ruby.

Jamis Buck, que es el autor de estos dos marcos dio una charla llamada Recovering from Enterprise en RubyConf 2008 acerca de cómo y por qué escribió esos marcos y por qué eso era una mala idea, que es bien vale la pena ver. (Simplemente sustituya "Python" cada vez que diga "Ruby" y todo será igual de válido.)

Answer 4

Lo intentaré de nuevo. Mi última respuesta se perdió la pregunta por una milla y se alejó del tema.

El uso de pseudo-código, la inyección de dependencias dice con:

class Person 
    def Chat() { 
    someOperation("X","Y","Z") 
    end 
end 
... 
Person.new().Chat() 

y adentro con:

class Person 
    initialize(a,b,c) 
    @a=a 
    @b=b 
    @c=c 
    end 
    def Chat() 
    someOperation(@a,@b,@c) 
    end 
end 
... 
Person.new("X","Y","Z").Chat() 

, y en general con poner el objeto y la llamada en diferentes archivos para. Propósitos de SCM.

Si "X", "Y" o "Z" son burlables (... si fueran objetos ... (!) ... (!) ...) no tienen nada que ver con si DI es bueno. De Verdad. :-)

DI es simplemente más fácil en Python o Ruby, como en muchas otras tareas, porque hay más de un enfoque de scripting, como dice Jörg; y también, por supuesto, menos de una cultura y una tendencia que dice que las constantes y los adaptadores se deben poblar en modelos y constantes globales.

En términos prácticos para mí DI es el primer paso para separar los parámetros de aplicación, constantes de API y fábricas en archivos separados para ayudar a que su informe de seguimiento de revisión parezca menos espagueti ("Fueron esos controles extra en el AppController a cambie la configuración ... o actualice el código ...? ") y más información, y más fácil de leer.

Mi recomendación: Siga usando DI ... :-)