Actually, in implementing this it struck me that DCI is kind of like DI
taken to then next level of abstraction. So your question isn’t really
that
out of place --to which I would say, you are right. DI really doesn’t
fit
Ruby, but DCI does bring something more to the table in the way it makes
you think about and implement you problem set.
Actually, I’m not sure DCI is all that great an idea. That remains to be
seen. My goal here was just to create a fairy solid implementation of
the
concept (I’d say I’m 80% of the way there at this point), so that people
could at least give it a try/use it as a reference.
I have a question… what problems does dependency injection solve that
duck typing does not?
As Rubyists we can compose in such a way that we expect objects which
quack
a certain protocol. The method protocol in use becomes a kind of
abstraction, allowing us to swap in other types of objects which quack
the
same, but may be completely different objects of a completely different
class with a completely different implementation.
Dependency injection seems like myriad complexity in order to solve a
problem that Ruby already solves by the very nature of its type system.
I
have used this sort of approach to simply compose the kinds of systems I
can’t fathom being able to build in statically typed languages.
So all that said, what does dependency injection offer Rubyists that
duck
typing does not?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.