On Wed, Apr 9, 2008 at 4:44 PM, Daniel B. [email protected]
DI has no place in Ruby. So says Jamis B. himself:
“I’ve since learned my lesson and have come to understand that
although DI is a nifty technique that works well in some environments,
it is wholly unnecessary in Ruby. Ruby sports an agility that Java
will never know, and can get by without such crutches.”
There’s a difference between dependency injection the pattern, and
It’s still a good idea to write classes that have their collaborators
passed in, rather than finding or creating them internally.
One of my favorite examples:
1. Not so great
@timestamp = Time.now
@timestamp = clock.now
#2 is better because it’s decoupled from the nondeterministic system
clock, and thus easier to test.
Sure, with ruby Mock Object libraries you can do things like:
…but this runs the risk of breaking unrelated code that also happens
to be called in the test. And no, that’s not a theoretical risk;
I’ve had real tests fail because I needed to deterministically test
time-based code and some other code (like, say, RSpec itself) depended
DI frameworks may be overkill in Ruby, but DI is still a good way of
breaking up your dependencies and keeping things decoupled.
Developer Blog: http://avdi.org/devblog/