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
the more #1 could potentially be desirable as an embodiment of the