"The Ruby way" (mixins and class reopening) vs. dependency injection

Actually when I came from Java world to ruby world the first thing that I was interested in is how do they manage dependencies. At that time I was using Google Guice in all java projects and I was really inspired by its clever design and ease of use. The first thing that I've done in ruby was my very own DI container that had approximately the same set of features as Google Guice - (it is still here on github but it is very outdated).

But now after 2 years of working with Rails/Ruby I think that DI is not needed here. The good article on DI in ruby is http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming it is actually an article about why DI is not needed by author of one of the first DI containers for ruby. It is definitely worth reading.

Well just because we can reopen classes in Ruby doesn't mean we always have to, you can think of reopening classes as the method of last resort. You have a library which does everything you need except for one method, rather than forking the whole library patching it and using your fork, you can simply reopen the class, redefine the method and you're in business again. This is not something you would do willy-nilly, but having the ability to do this is extremely useful.

Having said all of that, in Ruby we have a concept that can almost always be a good substitute for dependency injection - duck typing. Since there is no type checking you can pass any object into a function and as long as the object has the methods that the function would expect, everything will work fine.

Let us look at your example - it is not really class that is conducive to dependency injection, you would not write it like this in Java, for example, if you wanted to inject some dependencies. You can only inject through the constructor or through getters and setters. So let's rewrite this class in that way:

class Foo  def initialize(logger)    @logger = logger  endend

Much better we can now inject/pass in a logger into our Foo class. Let's add a method that would use this logger to demonstrate:

class Foo  def initialize(logger)    @logger = logger  end  def do_stuff    @logger.info("Stuff")  endend

In java if you wanted to create Foo objects with different types of loggers, all those loggers would have to implement the same interface in very literal sense (e.g. public class logger implements Loggable), or at least be child classes. But in Ruby as long as the object has an info method that accepts a string, you can pass it into the constructor and Ruby keep chugging along merrily. Let's demonstrate:

class Logger  def info(some_info)  endendclass Widget  def info(some_widget_info)  endendclass Lolcat  def info(lol_string)  endendFoo.new(Logger.new).do_stuffFoo.new(Widget.new).do_stuffFoo.new(Lolcat.new).do_stuff

With all 3 of the above instances of the Foo class calling the do_stuff method, everything will work fine.

As you can see from this example adhering to the principles of OO design is still important, but Ruby is somewhat less restrictive about what it will accept, as long as the right methods are there everything will be fine.

Depending on how you look at it duck typing either makes dependency injection totally irrelevant or makes it more powerful than ever.

The simple answer is that nothing in the Ruby language prevents you from writing re-usable classes. The common approach to using mix-ins and class reopening doesn't necessarily promote it, but the language doesn't actually prevent other approaches. Think of "The Ruby Way" as a subset of "The Things Ruby Can Do."

That said, I know that it's usually preferable to enforce a design decision with language constructs, and to my knowledge (which I will warn you is far from complete on the subject) DI isn't currently a core Ruby-ism. A bit of Googling found me some articles on the subject, though, leading me to believe that there are libraries to be found to add DI to Ruby, if you so desire (even though they seem to receive criticism from many Rubyists). Informative articles included these two, and this SO question. Hope that helps.