Inversion of Control in Ruby by passing classes - does it make anysense?

  • Thread starter Manuel Kiessling
  • Start date
M

Manuel Kiessling

Hello everyone,

I'm quite new to Ruby, with a strong background in PHP.

I had a great time finding my way around in Ruby, because it is a =
fantastic language. However, right now I'm a bit stuck regarding the =
issue of loose coupling / inversion of control / writing testable units.

I spent the last days reading a lot of articles, but feel sort of =
puzzled now.

As far as I can see, there are several approaches. I will start with my =
own, which probably is the weirdest of all - feel free to dissect it.

Let's say I have 2 classes, SomeClass and OtherClass, and SomeClass =
depends on OtherClass, because in some cases it needs to create an =
instance of this class, and in others it doesn't, which is why we can't =
simply pass an already created instance of OtherClass into SomeClass.

This is how it could be done using no DI at all:

class SomeClass
def do_something(a, b)
c =3D a + b
if (c > 5) then
o =3D OtherClass.new()
o.log(c)
end
end
end

s =3D SomeClass.new
s.do_something(1, 2)

Which of course doesn't allow me to replace "o" with a mock object for =
testing etc.


This is how it might be done using the fact that ruby classes are =
objects (my approach):

class SomeClass
def do_something(a, b, logObjectClass)
c =3D a + b
if (c > 5) then
o =3D logObjectClass.new()
o.log(c)
end
end
end

s =3D SomeClass.new
s.do_something(1, 2, OtherClass)

This way, I can inject into SomeClass which class to actually use - as =
long as whatever I pass using logObjectClass supports the expected =
protocol, all should be fine. I could easily inject a mock log object =
for my tests.

But, I couldn't find any articles recommending this approach, and I =
guess there's a reason for that...


Another solution which seems to be more along "the Ruby way" is this:

class SomeClass
def do_something(a, b)
c =3D a + b
if (c > 5) then
o =3D get_logger()
o.log(c)
end
end

def get_logger()
OtherClass.new()
end
end

// Replacing with mock object:
s =3D SomeClass.new
def s.get_logger()
MockLoggerClass.new()
end
s.do_something(1, 2)

Could someone help me to understand which approach is better, and why? =
Or if maybe I'm getting it completely wrong?

Thanks in advance,

--=20
Manuel
 
C

Chuck Remes

Hello everyone,

I'm quite new to Ruby, with a strong background in PHP.

I had a great time finding my way around in Ruby, because it is a fantastic language. However, right now I'm a bit stuck regarding the issue of loose coupling / inversion of control / writing testable units.

I spent the last days reading a lot of articles, but feel sort of puzzled now.

As far as I can see, there are several approaches. I will start with my own, which probably is the weirdest of all - feel free to dissect it.

Let's say I have 2 classes, SomeClass and OtherClass, and SomeClass depends on OtherClass, because in some cases it needs to create an instance of this class, and in others it doesn't, which is why we can't simply pass an already created instance of OtherClass into SomeClass.

This is how it could be done using no DI at all:

class SomeClass
def do_something(a, b)
c = a + b
if (c > 5) then
o = OtherClass.new()
o.log(c)
end
end
end

s = SomeClass.new
s.do_something(1, 2)

Which of course doesn't allow me to replace "o" with a mock object for testing etc.

Actually, all of the Ruby TDD or BDD frameworks include mocking frameworks that support this. Here's what it might look like in rspec:

it "should create instance of OtherClass" do
o = mock('other class')
OtherClass.should_receive:)new).and_return(o)

SomeClass.new.do_something(1, 2)
end

It's a valid technique and gets used quite a bit.

This is how it might be done using the fact that ruby classes are objects (my approach):

class SomeClass
def do_something(a, b, logObjectClass)
c = a + b
if (c > 5) then
o = logObjectClass.new()
o.log(c)
end
end
end

s = SomeClass.new
s.do_something(1, 2, OtherClass)

This way, I can inject into SomeClass which class to actually use - as long as whatever I pass using logObjectClass supports the expected protocol, all should be fine. I could easily inject a mock log object for my tests.

But, I couldn't find any articles recommending this approach, and I guess there's a reason for that...

It's not a bad idea and will work just fine. I have used this technique a couple of times. What I usually do is make that 3rd argument a default parameter so that by default it uses the class that I hardcode but I am free to override it (during testing) with a mock of my own.

e.g.

def do_something(a, b, klass = OtherClass)
c = a + b
if c > 5
o = klass.new
end
end

SomeClass.new.do_something(1, 2, MockClass) # inject my own
SomeClass.new.do_something(1, 2) # will use OtherClass by default

Another solution which seems to be more along "the Ruby way" is this:

class SomeClass
def do_something(a, b)
c = a + b
if (c > 5) then
o = get_logger()
o.log(c)
end
end

def get_logger()
OtherClass.new()
end
end

// Replacing with mock object:
s = SomeClass.new
def s.get_logger()
MockLoggerClass.new()
end
s.do_something(1, 2)

Could someone help me to understand which approach is better, and why? Or if maybe I'm getting it completely wrong?

I rarely see code structured like this. I wouldn't do it this way particularly since you have two better solutions that you listed above.

Ultimately, Ruby is flexible enough that you can accomplish your goal *cleanly* using multiple different techniques. I would use the ones you listed in the order that you listed them (best is first, etc).

Welcome to Ruby!

cr
 
J

Jeremy Bopp

Hello everyone,

I'm quite new to Ruby, with a strong background in PHP.

I had a great time finding my way around in Ruby, because it is a fantastic language. However, right now I'm a bit stuck regarding the issue of loose coupling / inversion of control / writing testable units.

I spent the last days reading a lot of articles, but feel sort of puzzled now.

As far as I can see, there are several approaches. I will start with my own, which probably is the weirdest of all - feel free to dissect it.

Let's say I have 2 classes, SomeClass and OtherClass, and SomeClass depends on OtherClass, because in some cases it needs to create an instance of this class, and in others it doesn't, which is why we can't simply pass an already created instance of OtherClass into SomeClass.

This is how it could be done using no DI at all:

class SomeClass
def do_something(a, b)
c = a + b
if (c > 5) then
o = OtherClass.new()
o.log(c)
end
end
end

s = SomeClass.new
s.do_something(1, 2)

Which of course doesn't allow me to replace "o" with a mock object for testing etc.


This is how it might be done using the fact that ruby classes are objects (my approach):

class SomeClass
def do_something(a, b, logObjectClass)
c = a + b
if (c > 5) then
o = logObjectClass.new()
o.log(c)
end
end
end

s = SomeClass.new
s.do_something(1, 2, OtherClass)

This way, I can inject into SomeClass which class to actually use - as long as whatever I pass using logObjectClass supports the expected protocol, all should be fine. I could easily inject a mock log object for my tests.

But, I couldn't find any articles recommending this approach, and I guess there's a reason for that...


Another solution which seems to be more along "the Ruby way" is this:

class SomeClass
def do_something(a, b)
c = a + b
if (c > 5) then
o = get_logger()
o.log(c)
end
end

def get_logger()
OtherClass.new()
end
end

// Replacing with mock object:
s = SomeClass.new
def s.get_logger()
MockLoggerClass.new()
end
s.do_something(1, 2)

What I'm about to suggest will generate warnings from Ruby and is
probably not the "best" way, but you could also replace OtherClass with
your MockLoggerClass with a simple assignment during your test:

OtherClass = MockLoggerClass # This generates a warning...
s = SomeClass.new
s.do_something(1, 2)


Ruby will warn you about replacing an already initialized constant,
namely OtherClass, but it should get the job done with a minimum of fuss
on your part.

One more option would be to override OtherClass.new and make it simply
call MockLoggerClass.new with the same arguments:

def OtherClass.new(*args)
MockLoggerClass.new(*args)
end

s = SomeClass.new
s.do_something(1, 2)


Among all the solutions, I don't know the best way, but I would probably
go with overriding OtherClass.new. Your second proposed solution isn't
bad either, but I wouldn't want to go that way just to make testing
easier/possible. I would need a good functional reason to break up the
code that way. Of course, division of labor in your implementation
isn't a bad reason. ;-)

-Jeremy
 
J

Joel VanderWerf

Hello everyone,

I'm quite new to Ruby, with a strong background in PHP.

I had a great time finding my way around in Ruby, because it is a fantastic language. However, right now I'm a bit stuck regarding the issue of loose coupling / inversion of control / writing testable units.

I spent the last days reading a lot of articles, but feel sort of puzzled now.

As far as I can see, there are several approaches. I will start with my own, which probably is the weirdest of all - feel free to dissect it.

Let's say I have 2 classes, SomeClass and OtherClass, and SomeClass depends on OtherClass, because in some cases it needs to create an instance of this class, and in others it doesn't, which is why we can't simply pass an already created instance of OtherClass into SomeClass.

This is how it could be done using no DI at all:

class SomeClass
def do_something(a, b)
c = a + b
if (c> 5) then
o = OtherClass.new()
o.log(c)
end
end
end

One way to do it (assuming you want to reuse the OtherClass instance):

class SomeClass
def do_something(a, b)
c = a + b
if c > 5
otherclass.log(c)
end
end

def otherclass
@otherclass ||= OtherClass.new
end
end

mock = SomeClass.new
mock.otherclass = MockOtherClass.new # or whatever
# note, you will have to define a writer
# (or use instance_variable_set)
 
R

Robert Klemme

tic language. However, right now I'm a bit stuck regarding the issue of loo=
se coupling / inversion of control / writing testable units.nds on OtherClass, because in some cases it needs to create an instance of =
this class, and in others it doesn't, which is why we can't simply pass an =
already created instance of OtherClass into SomeClass.ong as whatever I pass using logObjectClass supports the expected protocol,=
all should be fine. I could easily inject a mock log object for my tests.s there's a reason for that...

Certainly. But whether this reason also means that your approach is
bad is another question. Personally I find it totally valid and
natural to use a class object as /factory/ for instances. The other
approach, which might be a bit more Ruby like, is to use a block:

class SomeClass
# block as factory
def do_something_1(a, b, &log)
c =3D a + b
if (c > 5) then
o =3D log.call
o.log(c)
end
end

# block as callback
def do_something_2(a, b, &log)
c =3D a + b
if (c > 5) then
log.call(c)
end
end
end

sc.do_something_1(1,2) { OtherClass.new }
sc.do_something_2(1,2) {|item| OtherClass.new.log(item) }

Btw, if OtherClass is some kind of logger I would probably make the
factory a member of SomeClass, so you do not have to pass it into
every call.
What I'm about to suggest will generate warnings from Ruby and is
probably not the "best" way, but you could also replace OtherClass with
your MockLoggerClass with a simple assignment during your test:

OtherClass =3D MockLoggerClass =A0# This generates a warning...
s =3D SomeClass.new
s.do_something(1, 2)

This is not exactly the same as it does not allow control over the
created instance per instance. You basically change global state vs.
Manuel's approach with local state.
Ruby will warn you about replacing an already initialized constant,
namely OtherClass, but it should get the job done with a minimum of fuss
on your part.

One more option would be to override OtherClass.new and make it simply
call MockLoggerClass.new with the same arguments:

def OtherClass.new(*args)
=A0MockLoggerClass.new(*args)
end

s =3D SomeClass.new
s.do_something(1, 2)

Same problem: global vs. local state.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
J

Jeremy Bopp

This is not exactly the same as it does not allow control over the
created instance per instance. You basically change global state vs.
Manuel's approach with local state.

I agree, but I was approaching this from a minimal unit test standpoint
rather than a generally applicable part of Manuel's design. Would you
say that changing the global state in this way or in the other way I
suggested is still a problem in that case?

-Jeremy
 
R

Robert Klemme

I agree, but I was approaching this from a minimal unit test standpoint
rather than a generally applicable part of Manuel's design. =A0Would you
say that changing the global state in this way or in the other way I
suggested is still a problem in that case?

I cannot really tell. Maybe, if you need different loggers in
different unit tests and mix in multi threading to make your test
suite finish faster. :)

But I do know that global state is problematic. I guess you can find
plenty of evidence on the web (or reason about it for yourself /
according to your own code). It should be used with extra care. I
try to avoid it whenever possible and that approach has served me
well.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
J

Jeremy Bopp

I cannot really tell. Maybe, if you need different loggers in
different unit tests and mix in multi threading to make your test
suite finish faster. :)

But I do know that global state is problematic. I guess you can find
plenty of evidence on the web (or reason about it for yourself /
according to your own code). It should be used with extra care. I
try to avoid it whenever possible and that approach has served me
well.

I'll keep that in mind. Thanks for the tips. ;-)

-Jeremy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top