
"Unobtrusive Ruby" in Practice - jamesbritt
http://practicingruby.com/articles/shared/ozkzbsdmagcm
======
ggchappell
Nice. But I think the ideas can be restated in a way that is not especially
specific to Ruby. Rather, this gives us a way to judge code and languages
(does the language effectively support the writing of unobtrusive code?). It
also suggests directions in which the development of a language might go
(improving such support).

~~~
sandal
I agree. I went from the semi-general statements found in this post
(robots.thoughtbot.com/post/10125070413/unobtrusive-ruby) and cast them deeply
into Ruby examples, but I think that you could go in the other direction with
this and find that these concepts are already expressed by some existing
general OOD principles. However, that direction seems harder to trace than
just coming up with a code example for each point :)

------
sunkencity
Interesting, I agree that passing around classes in Ruby is not a good idea,
it's not easy to work with classes in ruby like dynamically finding them
depending on name in a certain namespace. Such things can be handled "better"
with a method missing chain or something.

Looking at the code: I'd be wary of chaining << to a custom class since it's a
source of error if << does something clever/extra and does not return self.

~~~
ssmoot
Is it really a good idea in any language though? I mean, if you're
instantiating in your consumer, it feels like you're not really leveraging
Composition.

It's OK to pass a Class to an IoC container (my own Ruby version:
[https://github.com/wiecklabs/harbor/blob/master/lib/harbor/c...](https://github.com/wiecklabs/harbor/blob/master/lib/harbor/container.rb)),
but if you're actually injecting them into your objects that feels wrong.

I really wish I were more eloquent and could explain why it feels that way.
:-/

I guess perhaps it just feels a bit primitive to be managing dependencies
manually in the manner of the example?

That said, I'd rather work with code that at least attempts to break out
dependencies like in the example, making testing and re-use much simpler over
code that's tightly coupled any day of the week.

EDIT: Just to be clear, after reading further, nit-picks aside, this really is
a great, eloquent article that makes several important concepts very
accessible. Very nicely done IMO.

------
stewbrew
"Take Objects, Not Classes"

But in Ruby, classes are objects with certain methods to create instances of
themselves, aren't they?

~~~
sandal
Yes, I was mirroring Mike's original headings and didn't change them, but this
is one area where my inner pedant was awoken. Glad to see I'm not alone!

The point here is simply that you should pass the object you directly want to
work with, not a class that can be used to generate that object. So if the
business of your method is to actually operate on a class object, that's fine.
But if you're calling new() on that class, probably not as fine.

