Over the past couple weeks, I’ve been doing a pile of reading (and screencast watching) on approaches to object-oriented design when using Ruby on Rails. I always take it as a good sign when I learn a new approach that makes me think “I want to go back and rewrite all my code this way.” (Although, of course, that would not be the best choice. It’s usually better to integrate new approaches with ongoing/new development rather than start over from scratch.) There’ve been a few of those moments during this recent reading, so I’ve decided to compile a list of what I’ve been looking at — both as a reference for myself, and to reinforce what I’ve been studying.
There is a pile of good stuff in these articles (and vids), but the single biggest for me is the point about segregating “business logic” (the methods that actually do the domain work) from persistence (database calls). There are a few different ways suggested for doing that here — I’m not sure yet which I favour.
Objects on Rails is probably the most comprehensive piece on this subject. It’s an ebook (viewable free on the website, or for $5 in non-DRM PDF, ePub and Kindle formats). There is little hand-holding in this book. Unless you are already well-versed in things like ruby meta-programming, it can be a challenging read (but well worth it even if you don’t get everything right away — some of the other materials that follow should help round out your understanding). I’ll go ahead and call this the essential piece out of this collection. It’s not to be skipped.
Some related articles include:
- The Secret to Rails OO Design (and the follow-up Better Ruby Presenters).
- Making ActiveRecord Models Thin
- Evaluating alternative Decorator implementations in Ruby
- Stubbing Is Not Enough
- Extracting Domain Models: A Practical Example
Something that came up a few times is how to apply the SOLID principles to Ruby development (since SOLID was conceptualized around typed languages like C++ as opposed to dynamic languages like Ruby).
The subject of