Any need for dependency injection in Dynamic Languages?

Question

In order to write testable C# code, I use DI heavily.

However lately I've been messing around with IronPython and found that as you can mock any methods/classes/functions etc... you like, the need for DI is gone.

Is this the case for dynamic langagues such as Python?

Instead of:

class Person(Address) {
...

You can have:

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

For dynamic languages and therefore following manaual DI for dynamic langagues is simply not needed.

Any advice on this?

Answer 1

Dependency Injection is also about how you wire things together --- which has nothing to do about the mockability of depended-on objects. There's a difference between having a Foo-instance that needs a Bar-connection of some kind instantiate it directly and having it completely ignore how it gets that connection as long as it has it.

If you use dependency injection you also gain better testability. But the converse isn't true. Easier testability by being able to overwrite anything doesn't bring the other advantages of dependency injection. There are many component/DI-frameworks for Python available exactly for these reasons.

Answer 2

I think you're presenting a question that seems to be about best practice but is actually about run-time performance.

Get rid of dependency injection? How can a software release manager sleep at night?

The tests for function to perform must surely slow the program down one or two tads.

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

You can use standard Python with classes... or you can assign function pointers to function pointer members. Just what kind of a beast is it...?? I know, I know. Python I think is difficult to define but I like it. And I like and think highly of dependency injection, not that I've had long where I'd think to assign such a lengthy name to the practice.

Answer 3

I strongly disagree with your statement that Dependency Injection is not needed in dynamically typed languages. The reasons for why DI is useful and necessary are completely independent of the typing discipline of the language.

The main difference is that DI in dynamically typed languages is easy and painless: you don't need a heavyweight framework and a gazillion lines of XML configuration.

In Ruby, for example, there are only two DI frameworks. Both were written by a Java programmer. Neither of the two frameworks is used by a single project. Not even by the author of those frameworks.

However, DI is used all over the place in Ruby.

Jamis Buck, who is the author of both of those frameworks gave a talk called Recovering from Enterprise at RubyConf 2008 about how and why he wrote those frameworks and why that was a bad idea, which is well worth watching. (Just substitute "Python" everytime he says "Ruby" and everything will be just as valid.)

Answer 4

I'll try again. My last answer missed the question by a mile and zoomed way off topic.

Using pseudo-code, dependency Injection says out with:

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

and in with:

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()

,., and generally in with putting the object and the call into different files for SCM purposes.

Whether "X", "Y" or "Z" are mockable (...if they were instead objects...(!)...(!)...) have nothing at all to do with whether DI is good. Really. :-)

DI is just easier in Python or Ruby, like a lot of other tasks, because there's more of a scripting approach, like Jörg says; and also of course less of a culture and a tendency saying that constants and adapters are to get populated into models and global constants.

In practical terms for me DI is the first step towards separating out those application parameters, API constants and factories into separate files to help make your revision tracking report look less spaghetti-like ("Were those extra checkins on the AppController to change the configuration..? Or to update the code...?") and more informing, and more easy to read.

My recommendation: Keep using DI... :-)