Endemic simplicity
I was setting up a new website for AutoMapper the other day, and needed to get both a domain name and integration into Heroku, where my site is hosted (for free, by the way). When you host your site with … Continue reading →
Archive for the ‘Rails’ Category
A question for Rubyists
I was checking out this post from Derick Bailey today, and something struck me rather odd. Not the “DI only enables testability” argument, but the ruby code:
class Foo def bar baz = Baz.new baz.do_something end end
I’ve been very curious to see what real Ruby applications look like written by real Rubyists. From the code I’ve seen, Ruby code written by C# developers looks vastly different than Ruby code written by seasoned Ruby developers. For example, I can’t really recall ever seeing something like “Baz.new” on anything that wasn’t a Model object or other primitive.
From what I’ve seen, composition in Rails apps happens more through modules and duck-typing, rather than new’ing up a dependency. In the above example, the Baz type doesn’t have any state, so there’s not really a reason to instantiate it at all.
This is the piece that I always question when I see code like this. In Rails production apps I’ve had the privilege of seeing, Dependency Injection was never necessary simply because there weren’t any dependencies to begin with. At most there were some modules/duck typing for static services like encryption. Otherwise, it just didn’t happen.
So a question (or two) for Rubyists:
- Would you ever write the above code in the first place?
- In one sentence (ha ha), how do you apply SOLID to your Ruby applications?
I’m working under the assumption that SOLID principles still apply, but in just far different ways. From my JavaScript experience, I’ve seen that SOLID and OO are still important, but they’re applied much differently, so I assume the same holds true for Ruby.
