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

Question

In studying mixins vs. dependency injection, I often hear the phrase \"the Ruby way.\" Often developers say something along the lines of

Ruby lets you reo

Answer 1

I totally agree. Dynamic languages are no substitutes for dependency injection. And nothing stops you from writing one for a dynamic language. Here's a dependency injection framework for Smalltalk: http://www.squeaksource.com/Seuss.html

Answer 2

Article about how to use IoC in Ruby You underestimate the power of IoC

With working samples.

UPDATE

Link is dead by now, here's the source https://github.com/alexeypetrushin/rubylang/blob/master/draft/you-underestimate-the-power-of-ioc.md

I used that IoC as a part of my web framework, I kinda re-created Ruby on Rails and it worked, but, it won't give significant advantage over RoR, had similar characteristics. So, it became a burden and I abandoned it, some details http://petrush.in/blog/2011/rad-web-framework .

Answer 3

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.

Answer 4

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.

Answer 5

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
  end
end

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")
  end
end

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)
  end
end

class Widget
  def info(some_widget_info)
  end
end

class Lolcat
  def info(lol_string)
  end
end

Foo.new(Logger.new).do_stuff
Foo.new(Widget.new).do_stuff
Foo.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.