I watched this talk, and I’m agreed that there’s no need in AOP technics
provided by DI - because Ruby is dynamic language and has
metaprogramming capabilities that are way more powerful and handy than
But I disagreed with the conclusion out of this fact - that there’s no
need for DI in Ruby. Because AOP is only one aspect of DI, and although
You don’t need AOP, You may benefit from others capabilities.
No matter how Your code looks like - lots of Lego building blocks (Java)
or free-design with plasticine, You has to solve following problems:
- where the component’s code is located.
- in what order should it be loaded.
- what configs does the component needs to be properly initialized.
- where those configs are stored.
- how to change configs in different environments (dev/test/prod
database settings, routes, …).
- where are dependencies for component and how they should be
- how to replace some components with custom implementation (without
examining its code and monkey-patching).
- how to assembly parts of application for specs/tests.
- how to restore state after each spec/test (isolate it from each
- how to control life-cycle of dynamically created components.
- connecting components to assemble an application.
DI simplifies these tasks and some of them solves completely
And if You think that You don’t need any structure and want complete
freedom - why do You use Rake?
It limits Your freedom to work with the Ruby plasticine and introduce
extra abstraction, so why do You use it?