Presenters First January 12, 2012 Tweet
You’ve probably seen the recent Object-Oriented Ruby revival that’s been happening across the Ruby community lately. I’ve been watching as well and have trying to find ways to apply the concepts back to my own work. But all along there’s been something that just hasn’t clicked for me yet. It’s rainbows and unicorns when you’re TDDing and have really simple usage of your objects, but then when they need to be persisted (or used in a form in Rails) we’re forced to add on ActiveRecord/ActiveModel/ORM-du jour layers to comply.
Today I was at Heroku’s Waza conference and after watching Corey Haines speak about his outside-in, 5-whys driven development and I was inspired immediately to try to work through some of his ideas for myself. But considering I wanted my application to grow using simple objects, I was torn between excitement and knowing I would reach those same pain points again.
So I went up and talked to Corey for a bit and explained my dilemma and told him about what I had been trying. He said, “Well, I’ve been using presenters in my Rails forms.” That struck a deep chord with me.
What I’ve been doing – and what I’ve seen many other’s proposing – is designing simple, unencumbered, bottom-up, TDD’d objects that turn into encumbered data objects, through decoration or conversion to an ActiveRecord object. Corey’s suggestion of an outside-in, “programming by wishful thinking” takes things from a different angle.
Starting with HTML of what you want, replace the key variable parts with an method calls an object or objects your view deals with, making up the best sounding API as you go (wishful thinking) and let that drive out the API your lower level objects.
In this way, I feel that a “presenter first” approach is going to result in the simplest outcome. Presenters aren’t intended to be complete data or behavior APIs. They function as simple objects to provide the API that’s needed to fulfill the needs of your view. You should be able to develop, at least, a read-only, functional version of your application. Then, when you’re ready, you can make the data object/persistence decision that make sense.
This clicks better for me and it’s how I plan to approach my next breakable toy/side projects. We’ll see how it goes.