4 ms·

"Unobtrusive Ruby" in Practice

66 points by jamesbritt 15y ago

ggchappell 15y ago
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 15y ago
  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 15y ago
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 15y ago
  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/container.rb 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.
stewbrew 15y ago
"Take Objects, Not Classes" But in Ruby, classes are objects with certain methods to create instances of themselves, aren't they?
- sandal 15y ago
  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.

66 points by jamesbritt 15y ago

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 15y ago
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 15y ago

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 15y ago
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/container.rb 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.

stewbrew 15y ago

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

sandal 15y ago
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.