"Unobtrusive Ruby" in Practice | Hacker News Reader

"Unobtrusive Ruby" in Practice

practicingruby.com

66 pointsjamesbritt6 comments

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).

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 :)

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.

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...), 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.

"Take Objects, Not Classes"

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

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.

Reply on news.ycombinator.com