Ruby dependency injection libraries

Question

I've been looking at some Ruby dependency injection libraries. In particularly, I checked out Needle and Copland. They've been around for quite awhile, yet not a lot of usages.

What are some of the pros and cons of using these two libraries? It sure seems like a lot of libraries / frameworks out there could make good use of these two libraries, e.g. Merb / Datamapper's Hook.

Answer 1

Jamis Buck, who wrote Copland and Needle, posted here about Needle, dependency injection and their usefulness in a Ruby world.

It's long but worth reading, but in case you want the single paragraph most relevant to your question, I'd suggest this one, from just before the end:

DI frameworks are unnecessary. In more rigid environments, they have value. In agile environments like Ruby, not so much. The patterns themselves may still be applicable, but beware of falling into the trap of thinking you need a special tool for everything. Ruby is Play-Doh, remember! Let’s keep it that way.

HTH

Answer 2

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/: this is another, much less opinionated article than the James Buck article. Bottom line is that you don't need dependency injection because ruby provides plenty of good alternatives that work just as well and that don't really exist in the Java world.

One of those alternatives is mixins, which is something Java does not have and the other one is the ability to override/redefine just about anything in the language. Other features include dynamic typing where basically you can send any message to any object and if it happens to provide an implementation for that message, things just work. All these things work together to remove much of the need for a DI framework. The design pattern as such is still valid in Ruby as well and sometimes it just makes sense to use it.

Another point about DI that Alexey Petrushin above also makes is that dependency injection is primarily a design pattern and that the tooling is secondary and mostly about getting rid of the tediousness of certain things in Java. In ruby, you can trivially emulate most of what spring or guice do for you in Java. So a full blown dependency injection framework is essentially redundant in Ruby.

That being said, sometimes having a DI framework is kind of nice since ultimately it can take away some of the tediousness of wiring stuff up. I can't vouch for any Ruby specific DI frameworks but I know of a lot of Ruby projects that ultimately got rewritten in another language (Java even) because the playdoh nature of things causes things to become hard to maintain/extend. I suspect this has a lot to do with developers shooting themselves in the foot with the various powerful language features. Having a DI framework imposes a bit of structure and idioms that may help prevent this.