Tom,

I think like many languages communities get segregated on practices. I
wouldn't agree that Rubyists avoid the SOLID principles. I teach them
pretty frequently in my workshops. As a first pass I would have coded the
example like this:
https://gist.github.com/halogenandtoast/3c8da80405de5237feb5

Which would have followed dependency injection. Different people have
different principles but I think practices (if at least consistent on a
project) are generally a good thing.


On Wed, Mar 6, 2013 at 4:15 PM, Tom Kos <lists / ruby-forum.com> wrote:

> I'm java programmer diving into Ruby language (not rails stuff). Looking
> at ruby codebases I see a lot of code like this
> https://gist.github.com/anonymous/5101448.
>
> Take a look at the SchedulerJob definition:
>
> class SchedulerJob
>
>   def run
>     expired_requests = RequestSchedule.new.fetch_all_expired
>     RequestToQueuePusher.new.enqueue(expired_requests)
>   end
>
> end
>
> It explicitly creates RequestSchedule and RequestToQueuePusher. Those
> two objects are plain stateless "services". This code works fine, but
> for me it introduces very high coupling between SchedulerJob and those
> classes. In Java we'd normally inject their instances in constructor and
> don't use "new" inside to create them.
> I'm not sure why this is not popular technique in Ruby. I was trying to
> google for that and all I got can be told as "Ruby doesn't need
> dependencies injection". Why is it so? I know stubbing RequestSchedule
> or RequestToQueuePusher for tests is easy (with rspec e.g.), but
> testability is not the only point.
> Is this really Ruby way for OOP? For me it breaks SOLID principles I
> know. I'd like to code in Ruby the Ruby way but it seems to be
> completely different than in Java, and I thought OOP concepts and
> practices should not vary between languages.
>
> How do you approach such situations, or you don't care and just put
> "new" every time you want to reach dependent object?
>
> --
> Posted via http://www.ruby-forum.com/.
>
>