From: Peter <lumbergh@...>
Date: 2013-03-07T08:37:13+09:00
Subject: Re: Coupling vs providing dependencies in Ruby

--047d7b5d457660b10a04d7492323
Content-Type: text/plain; charset=ISO-8859-1

Tom:

I agree mostly with you. There is nothing stopping you from injecting
outside dependencies on initialization and defaulting to the expected
dependencies; in fact, if we had stuck to that in our Rails app codebase
from the beginning, then our unit tests might have actually run quickly
from the get-go.

I think that a lot of Ruby/Rails devs are only first starting to run up
against large monolithic codebases with a massive coupling problem which is
creating negative side effects around such things as test run time and
maintainability, and are (re)discovering these principles that Java devs
may have already known about for some time.

So please, bring your (well-argued) opinion here! That said...

Another possible pattern I have been toying around with which could satisfy
your requirement (without requiring a possibly lengthy/ugly/disturbing
argument list to the initialization routine) is to define a few slightly
clever instance methods as proxies. Another advantage of this approach is
that you can specify all your class' exterior dependencies right up front
at the top of the class definition, so if you are getting a little too
coupled for your own good, it will be obvious:

class SchedulerJob

  # BEGIN exterior dependencies
  def request_schedule_class
    defined?(super) ? super : RequestSchedule
  end
  def request_to_queue_pusher_class
    defined?(super) ? super : RequestToQueuePusher
  end
  # END exterior dependencies

  def run
    expired_requests = request_schedule_class.new.fetch_all_expired
    request_to_queue_pusher_class.new.enqueue(expired_requests)
  end

end

Then in your unit test or what have you, you define a module like so

module CouplingIsForPornStubs

  def request_schedule_class
    my_tests_fake_schedule_class # or Class.new, or mock, or what have you
  end

  def request_to_queue_pusher_class
    raise "come on, this is too much coupling, it's like a bukkake"
  end

end

And then later on in the actual test case you just do

  sj_under_test = SchedulerJob.new
  sj_under_test.extend CouplingIsForPornStubs
  assert_raise { sj_under_test.run }

And now your class instance under test will magically defer to your
module's version of the methods (or classes) first, then to its own.

I have some code that cleans this up and patterns it out, but I haven't put
it anywhere (where "anywhere" == "github") yet. :)

-Peter


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

> Thanks, this is more or less how I'd do that. I'd maybe just add default
> arguments' values like:
>
> class SchedulerJob
>
> def initialize(schedule = RequestSchedule.new, pusher =
> RequestToQueuePusher.new)
>     @schedule = schedule
>     @pusher = pusher
>   end
>
>   ...
>
> end
>
> I'm far from stating that rubyists avoid SOLID principles, but it's hard
> to spot codebases with dependencies injected on regular basis.
>
> The only question remaining is that even using dependency injection you
> still need to "new" your dependencies somewhere. In Java you got things
> like Spring or Guice (frameworks for wiring up all stuff together). But
> I guess in ruby it may be easily done with default arguments doing "new"
> implicitly. Classes are still coupled but I think it may be bit better
> than "new" in methods.
>
> --
> Posted via http://www.ruby-forum.com/.
>
>


-- 
http://www.politifact.com/
http://www.factcheck.org/
http://insureblog.blogspot.com/2012/08/the-myth-of-unbiased-media.html
http://www.cracked.com/article_16656_6-brainwashing-techniques-theyre-using-you-right-now.html

--047d7b5d457660b10a04d7492323
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Tom:<div><br></div><div style>I agree mostly with you. The=
re is nothing stopping you from injecting outside dependencies on initializ=
ation and defaulting to the expected dependencies; in fact, if we had stuck=
 to that in our Rails app codebase from the beginning, then our unit tests =
might have actually run quickly from the get-go.</div>
<div style><br></div><div style>I think that a lot of Ruby/Rails devs are o=
nly first starting to run up against large monolithic codebases with a mass=
ive coupling problem which is creating negative side effects around such th=
ings as test run time and maintainability, and are (re)discovering these pr=
inciples that Java devs may have already known about for some time.</div>
<div style><br></div><div style>So please, bring your (well-argued) opinion=
 here! That said...</div><div style><br></div><div style>Another possible p=
attern I have been toying around with which could satisfy your requirement =
(without requiring a possibly lengthy/ugly/disturbing argument list to the =
initialization routine) is to define a few slightly clever instance methods=
 as proxies. Another advantage of this approach is that you can specify all=
 your class&#39; exterior dependencies right up front at the top of the cla=
ss definition, so if you are getting a little too coupled for your own good=
, it will be obvious:</div>
<div style><br></div><div style><span style=3D"font-family:arial,sans-serif=
;font-size:13px">class SchedulerJob</span><br></div><div style><span style=
=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div styl=
e>
<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 # BEGIN ext=
erior dependencies</span></div><div style>=A0 def request_schedule_class</d=
iv><div style>=A0 =A0 defined?(super) ? super : RequestSchedule</div><div s=
tyle>=A0 end</div>
<div style>=A0 def request_to_queue_pusher_class</div><div style>=A0 =A0 de=
fined?(super) ? super : RequestToQueuePusher</div><div style>=A0 end</div><=
div style>=A0 # END exterior dependencies</div><div style><br></div><div st=
yle><div>
=A0 def run</div><div>=A0 =A0 expired_requests =3D request_schedule_class.n=
ew.fetch_all_expired</div><div>=A0 =A0 request_to_queue_pusher_class.new.en=
queue(expired_requests)</div><div>=A0 end</div></div><div style><br></div><=
div style>
end</div><div style><br></div><div style>Then in your unit test or what hav=
e you, you define a module like so</div><div style><br></div><div style>mod=
ule CouplingIsForPornStubs</div><div style><br></div><div style>=A0 def req=
uest_schedule_class</div>
<div style>=A0 =A0 my_tests_fake_schedule_class # or Class.new, or mock, or=
 what have you</div><div style>=A0 end</div><div style><br></div><div style=
>=A0 def request_to_queue_pusher_class</div><div style>=A0 =A0 raise &quot;=
come on, this is too much coupling, it&#39;s like a bukkake&quot;</div>
<div style>=A0 end</div><div style><br></div><div style>end</div><div style=
><br></div><div style>And then later on in the actual test case you just do=
</div><div style><br></div><div style>=A0 sj_under_test =3D SchedulerJob.ne=
w</div>
<div style>=A0 sj_under_test.extend CouplingIsForPornStubs</div><div style>=
=A0 assert_raise { sj_under_test.run }</div><div style><br></div><div style=
>And now your class instance under test will magically defer to your module=
&#39;s version of the methods (or classes) first, then to its own.</div>
<div style><br></div><div style>I have some code that cleans this up and pa=
tterns it out, but I haven&#39;t put it anywhere (where &quot;anywhere&quot=
; =3D=3D &quot;github&quot;) yet. :)</div><div style><br></div><div style>-=
Peter</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Mar 6, 2013 at 4:45 PM, Tom Kos <span dir=3D"ltr">&lt;<a href=3D"mailto:li=
sts@ruby-forum.com" target=3D"_blank">lists@ruby-forum.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Thanks, this is more or less how I&#39;d do =
that. I&#39;d maybe just add default<br>
arguments&#39; values like:<br>
<br>
class SchedulerJob<br>
<br>
def initialize(schedule =3D RequestSchedule.new, pusher =3D<br>
RequestToQueuePusher.new)<br>
=A0 =A0 @schedule =3D schedule<br>
=A0 =A0 @pusher =3D pusher<br>
=A0 end<br>
<br>
=A0 ...<br>
<br>
end<br>
<br>
I&#39;m far from stating that rubyists avoid SOLID principles, but it&#39;s=
 hard<br>
to spot codebases with dependencies injected on regular basis.<br>
<br>
The only question remaining is that even using dependency injection you<br>
still need to &quot;new&quot; your dependencies somewhere. In Java you got =
things<br>
like Spring or Guice (frameworks for wiring up all stuff together). But<br>
I guess in ruby it may be easily done with default arguments doing &quot;ne=
w&quot;<br>
implicitly. Classes are still coupled but I think it may be bit better<br>
than &quot;new&quot; in methods.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Posted via <a href=3D"http://www.ruby-forum.com/" target=3D"_blank">http://=
www.ruby-forum.com/</a>.<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div><a href=3D"http://www.politifact.com/" target=3D"_blank">http://www.po=
litifact.com/</a></div><div><a href=3D"http://www.factcheck.org/" target=3D=
"_blank">http://www.factcheck.org/</a></div>
<div><a href=3D"http://insureblog.blogspot.com/2012/08/the-myth-of-unbiased=
-media.html" target=3D"_blank">http://insureblog.blogspot.com/2012/08/the-m=
yth-of-unbiased-media.html</a></div><div><a href=3D"http://www.cracked.com/=
article_16656_6-brainwashing-techniques-theyre-using-you-right-now.html" ta=
rget=3D"_blank">http://www.cracked.com/article_16656_6-brainwashing-techniq=
ues-theyre-using-you-right-now.html</a></div>

</div>

--047d7b5d457660b10a04d7492323--