I don't know, Steve, it looks like you're creating classes with long scary names just to "encapsulate" Ruby one-liners; your whole DictionaryPresenter class (for instance) boils down to:<p><pre><code> Post.all.inject(Hash.new {|h, k| h[k] = []})
{|hash, post| hash[post.name[0]] = post; hash }
</code></pre>
You might be right that the forest of classes you're creating will be useful in the long run. But this is exactly the slippery slope that the Gang of Four disciples fell down in Java.<p>I think using the phrase "Plain Old $X Object" might be a warning sign.<p>Any time you write a post talking about learning OO, and your example class hierarchy includes classes that do nothing but wrap things that are already idiomatic in the language, expect your friends and those who care to jump on you to find and squash the radioactive object bees that are trying to burrow their way into your spinal column.
What's not mentioned here is how you decide <i>not</i> to extract something.<p>I think it's true that there is a class of novice programmers who will always just use whatever frameworks they are given, and write things out inline, never searching for a better way because they just don't have the natural curiosity (or they've never been shown the light) to seek out the better ways.<p>It's also true that to master a programming language you have to practice using all its abstractions. Ruby has a very pleasing and simple way to break down concerns, and clearly this is a tool you need in your box to write great Ruby code.<p>The true level of mastery is when you understand the cost-benefit of all this. For instance, breaking everything down into one-line methods is only of benefit if those methods are a non-leaky abstraction and make conceptual sense on their own. It's not inherently true that a 10-line method is harder to read—one ten-line method is much shorter than 10 one-line methods.<p>The effect is even more powerful with classes. Every class file you add is adding to the overhead of understanding the program. In order for that to be beneficial, you have a greater-than-linear improvement in program power and flexibility. Even if some extraction seems reusable, it might require tweaks every time you attempt to make a new use of it, or it might be a leaky abstraction that introduces bugs that cost you time down the line. What makes the true master are not principles about how long methods and classes should be, but rather how to factor the logic in such a way as to maximize re-use and conceptual integrity.<p>Finally, you must always be cognizant of the YAGNI principle. In a Rails app, you are writing code for a discrete problem domain where reusability may be limited. Taking the time to factor things truly beautifully is more worth it at the Gem/Framework level than the application level because there is much greater opportunity for reuse.
To those who are attacking this article. I think, Steve unfortunately has chosen a somewhat bad example to illustrate a very good point.<p>I have seen countless examples of complex payment logic shoved down into User model (or CreditCard model), because developer did not had the foresight to see that Payment logic does not belong in User or in CreditCard model.<p>About functional or using higher order functions - yeah go for it. The great thing about Ruby I think is - you can still use best of OO patterns with minimum amount of heavy lifting and sprinkle blocks and lambdas - resulting in pretty neat design overall.<p>Also, functional code != good code sometimes (<a href="http://www.drmaciver.com/2008/08/functional-code-not-equal-good-code/" rel="nofollow">http://www.drmaciver.com/2008/08/functional-code-not-equal-g...</a>)
Helpers.<p>Enjoyed the post, but Rails also provides helpers to 'help' you with view specific logic. Granted, this might not be as fun as a plain Ruby class, but I've used helpers extensively on various projects and whenever I join an existing project, it's one of the first places I look with dealing with the view layer.<p>One of the nice Rails conventions.
This code he calls good:<p><pre><code> DictionaryPresenter.new(PostCategorizationPolicy, Post.all).as_dictionary
</code></pre>
Well, it smells like typical java overengineering. Why stop at that, let's go full way to:<p><pre><code> DictionaryPresenterFactory.new(PostCategorizationPolicyStrategy, Post.collect(CollectionStrategy::All)).present</code></pre>
In this blog post, the author is reifying concepts and improving separation of concerns(1). This is basic software development. Which makes me wonder why the OP got the impression this kind of thing was "secret"?<p>(1)The usual warnings about premature optimization apply.
One thing that people seem to forget about object orientation: when you're not actually using an object to represent state, but you still want to inherit and/or separate functionality, there is a simple way to do it while avoiding the creation of a bunch of junk objects that do nothing besides waste heap space and get garbage collected on the next cycle:<p>STATIC/CLASS METHODS.