Better Ruby Presenters

My last blog post caused a bit
of a stir in some circles. I got a bunch of emails. Apparently, I need to expand
on a few things. So here we go. Let's rap about the Presenter pattern, shall we?

No seriously, helpers suck

In Ruby, everything is an object. Every bit of information and code can be
given their own properties and actions. - ruby-lang.org/about

... except helpers. Why is it in Ruby that everything is an object, even
integers, yet as soon as we need to format a date, we all turn into Dijkstra and
bust out structured programming? Actually, come to think of it, Dijkstra
wouldn't even write any code, because it's beneath him, but you get the idea.
(if you don't get this, it's a joke. About proofs, telescopes, and CS...)
Helpers are like a compliment that you don't want to give, but feel obligated
to: "Yeah, I mean, well, you tried, and that's what counts, right?"

This is the topic of a future post, but when programming in a langauge, you want
to work with its primary methods of abstraction. In Ruby, that's objects, and
there's a good reason for that: functions don't provide a sufficient amount of
power to tackle hard problems. I don't want to get into this either, but there's
a reason that objects exist, and that nobody's making procedural languages
anymore. No biggie. C has a special place in my heart.

But I digress: objects > functions. At least in the context of getting stuff
done in Ruby. This pretty much applies to most of the rest of the points in this
post, so just keep that in the back of your brain.

Why not a class method?

Well, first of all, class methods also suck. Here's the
issue: Can you tell me the difference between these two methods?

Yep, that's right. You can see it clearly from the last two lines: class methods
are functions that happen to be namespaced. That means they're slightly better,
but really, DictionaryPresenter.as_dictionary(something) might as well just be
a helper. At least as_dictionary(something) is shorter.

Here's another reason: I didn't make that method be a class method, even though
there was no state, because a really real presenter (I mean, that was a real
world example, but...) generally works a little different. Usually, I make
presenters that actually stand in for the objects they're presenting. Check
this out. Here's the presenter I showed you:

... or close to this. There was an 'other' category, and a few other things...
but you get the idea. Now, instead of this:

@posts = DictionaryPresenter.new(Post.all).as_dictionary

You do this:

@posts = DictionaryPresenter.new(Post.all)

And the presenter actually stands in for the hash. A subtle but important
difference. This gives you more options, because you have a real, live object
instead of just some random processing. With this simplistic presenter, you
might not see a huge benefit, but often, you'll want something a bit more
complicated. And since this was what I had in my head, I didn't make
as_dictionary be a static method.

Oh, and presenters that decorate a single object rather than a collection
often implement method_missing, so that you only add methods rather than
hide most of them. Some don't. It depends.

Blocks vs. Policy

I also showed off a Ruby version of a design pattern known as the Policy
pattern, or sometimes the Strategy pattern. Turns out that Policy is often
a bit heavyweight for Ruby, especially in an example like this, so I wanted
to show you an alternate version of it, taking advantage of a Ruby feature:
blocks.

While this is shorter, and a bit more Rubyish, it also means that we lose the
reification of
our concept of a policy. While this is shorter, I find it more
confusing. Why am I giving this one line block to the presenter? It's not really
clear to me. And I can't give a better name to item... and if I want to change
the policy, it has to be done in every place we use the presenter...

This does get to the root of another thing that will end up being a follow-up:
What's the difference between closures and objects? If you don't know, maybe
this will get you thinking:

This is too verbose

I switched the arguments around, because it reads better. When writing blog
posts, you have to balance writing code samples that explain what you're
trying to say, and ones that are 'real.' I tend to be a bit more verbose with
things like this, because it's easier for someone who just jumps in to remember
what all the parts are... then again, by not showing the 'real code,' people
might end up implementing the crappy, verbose version. It's always a trade-off,
and I may or may not make the right choice. It happens.

And yes, even earlier in this blog post: I said DictionaryPresenter and I'd
really just say Dictionary.

Where does all of this go?

You've got two options, and only one of them is good: You should make a
directory in app for your presenters. In this case, I'd be running
touch app/presenters/dictionary.rb pretty quick. The other case is to
put things in lib. This whole debacle uncovers something that @avdi went
on a rant about over the last few days: models don't have to inherit from
anything. Here's what Wikipedia says about models:

The model manages the behaviour and data of the application domain, responds
to requests for information about its state (usually from the view), and
responds to instructions to change state (usually from the controller). In
event-driven systems, the model notifies observers (usually views) when the
information changes so that they can react.

See anything about "saves stuff to the database?" Okay, 'manages... data' could
be, but the point is, it's not required. Models are the reification of a
concept that exists in your application domain. Persistance is not required for
every concept.

Therefore, if it relates to your problem domain, it goes in app. If it doesn't,
it goes in lib. Something like Dictionary? Depends on how important you think
it is. It's probably pretty important; that's why you made it a class.

Design Patterns? Are you serious?

Yes. Design patterns don't suck, Design patterns in Java suck. I'm not even
going to start this one here, expect more in this space soon.

Design patterns are great, and they're totally useful in Ruby.

In conclusion: A shout-out

I hope you've enjoyed this small digression on Presenters. If you're gonna use
presenters in your application, I encourage you to write simple ones as simple
Ruby classes, but if they get slightly more complicated, you need to check out
Draper by my buddy Jeff Casimir. It lets
you do stuff like this: