4 ms·
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
by 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 agoIs 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.