Tom,

I think like many languages commun= ities 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:=A0https://gist.github.c= om/halogenandtoast/3c8da80405de5237feb5

Which would have followed dependency injection. Differe= nt people have different principles but I think practices (if at least cons= istent 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). Lookin= g
at ruby codebases I see a lot of code like this
htt= ps://gist.github.com/anonymous/5101448.

Take a look at the SchedulerJob definition:

class SchedulerJob

=A0 def run
=A0 =A0 expired_requests =3D RequestSchedule.new.fetch_all_expired
=A0 =A0 RequestToQueuePusher.new.enqueue(expired_requests)
=A0 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 an= d
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/.