I have a choice to make about a class interface. This is a very very
simplified “foo” demo of that choice.
#1
class Foo
def initialize(bar) @bar = bar
end
def okay?
bar.okay?
end
end
bar = Bar.new
Foo.new(bar)
Or #2
class Foo
def initialize( opts ) @okay = opts[:okay]
end
def okay?
@okay
end
end
bar = Bar.new
Foo.new(:okay => bar.okay?)
Now, my inner OOP Angel is telling me to take door #2 in order to
avoid strong coupling between Bar and Foo. But, my Red Ruby Devil is
saying “Duck typing, you fool. It doesn’t matter anymore!”
Is he right? Has Ruby completely changed the game? If so, why aren’t
more Rubyists using OStruct-esque option passing?
Now, my inner OOP Angel is telling me to take door #2 in order to
avoid strong coupling between Bar and Foo. But, my Red Ruby Devil is
saying “Duck typing, you fool. It doesn’t matter anymore!”
Is he right? Has Ruby completely changed the game?
I don’t see why that would be true in this case. In #1, Foo’s
implementation depends on Bar’s public interface, whereas in #2,
there is no coupling at all between them.
Put another way: duck typing is still, in a sense, typing. In #1,
you aren’t constrained to pass in a Bar, specifically, but you must
still pass in an object which satisfies the same un-named object
protocol as instances of Bar do.
(Perhaps we should call it “ninja typing”?)
If so, why aren’t more Rubyists using OStruct-esque option passing?
Ruby doesn’t make it as frictionless as it could be, particularly if
you want default values for your options.
That said, I’m not sure that the issue of coupling necessarily settles
the question. The more actual behavior (rather than POD) embodied by
Bar,
the more #1 could potentially be desirable as an embodiment of the
Strategy Pattern.