Virtuous Code » patterns

Modeling the World with Prototypes

Avdi Grimm — Tue, 11 Dec 2012 14:00:00 +0000

This post started out as the second half of an article on prototype-based OO design for Gregory Brown’s Practicing Ruby. For an introduction to the prototyped view of the object world, and to follow along on an adventure in making Ruby act like a prototype-based language instead of a class-based one, you should go check out that article. Unlike the Practicing Ruby article, which is more about experimentation, this post focuses on the Prototype Pattern—a practical way to simplify your object models while still using classes.

A monster menagerie

Let’s say we’re writing a dungeon-crawl-style game in the vein of Nethack. So along with the rooms and items that we’d expect to find in a text adventure game, there are also various semi-randomly-generated monsters who periodically confront the hero. Different types of monster have different stats, such as health, speed, and strength. They each have their own types of attack as well.

We’d also like to be able to load up the list of monster types at run-time, from a user-editable file like this:

gnome:
  attack_text: hits you with a club!
  max_hit_points: 8
  strength: 5
  speed: 9
troll:
  attack_text: attacks you with a pickaxe!
  max_hit_points: 12
  strength: 10
  speed: 5
rabbit:
  attack_text: bites you with sharp, pointy teeth!
  max_hit_points: 50
  strength: 50
  speed: 50

One way to model different monster types would be like this:

class Monster
  attr_reader :health
  def initialize
    @health = max_hit_points
  end
end

class Gnome < Monster
  def name
    "gnome"
  end

  def attack_text
    "attacks you with a pickaxe"
  end

  def max_hit_points
    8
  end

  def strength
    5
  end

  def speed
    9
  end
end

g = Gnome.new
# => #

Here there is a Monster base class, and a subclass for each type of monster. But this doesn’t really lend itself to dynamically loading arbitrary monster types from a file, so we look for other approaches.

Definitions and instances

We experiment with one design that uses MonsterDefinition classes to hold the static attributes of different monsters. A MonsterDefinition can be told to #spawn a Monster instance. The Monster instance has a reference back to its definition, as well as an instance-specific health meter (initialized based on the max_hit_points of the MonsterDefinition).

class MonsterDefinition
  attr_accessor :name,
                :attack_text,
                :max_hit_points,
                :strength,
                :speed

  def initialize(attributes={})
    attributes.each do |name, value|
      public_send("#{name}=", value)
    end
  end

  def spawn
    Monster.new(self)
  end
end

class Monster
  attr_reader :definition
  attr_accessor :health

  def initialize(definition)
    @definition = definition
    @health = definition.max_hit_points
  end
end

gnome_def = MonsterDefinition.new(
  name: "gnome",
  attack_text: "attacks you with a pickaxe!",
  max_hit_points: 8,
  strength: 5,
  speed: 9)

g = gnome_def.spawn
# => #
# @definition=
# #
# @attack_text="attacks you with a pickaxe!",
# @max_hit_points=8,
# @name="gnome",
# @speed=9,
# @strength=5>,
# @health=8>

This approach seems promising. But as we reflect on it, we realize that we’re probably going to keep adding more of these definition/instance pairs of classes. RoomDefinition / Room, ItemDefinition / Item, etc. This feels like an awful lot of ceremony.

Cloning creatures

Finally, we hit upon using the Prototype Pattern. In this version, there is only one class: Monster. It has slots for both static attributes (like name, and strength), and dynamic attributes like health.

class Monster
  attr_accessor :name,
                :attack_text,
                :max_hit_points,
                :strength,
                :speed,
                :health

  def initialize(attributes={})
    attributes.each do |name, value|
      public_send("#{name}=", value)
    end
  end

  def initialize_dup(prototype)
    self.health = prototype.max_hit_points
    super
  end

end

To initialize our game’s bestiary of possible monster types, we load up the YAML-formatted monster file and initialize a Monster for each entry. Dynamic attributes like health are left blank for now. These are our prototypes.

require 'yaml'
bestiary = YAML.load_file('monsters.yml').each_with_object({}) do
  |(name, attributes), collection|
  collection[name] = Monster.new(attributes.merge(name: name))
end

When we want to set up a player encounter with a monster, we simply find the appropriate prototype monster, and duplicate it. The customized #initialize_dup method in Monster takes care of setting up an initial health meter for the cloned monster.

rabbit = bestiary['rabbit'].dup
# => #
# @attack_text="bites you with sharp, pointy teeth!",
# @max_hit_points=50,
# @name="rabbit",
# @speed=50,
# @strength=50>

we can easily generate random monsters:

random_foe = bestiary.values.sample.dup
# => #
# @attack_text="attacks you with a pickaxe!",
# @max_hit_points=12,
# @name="troll",
# @speed=5,
# @strength=10>

This solution is both shorter and simpler than any of the others we tried.

Representing Forms

The Prototype Pattern is, in my experience, one of the more overlooked of the Gang of Four patterns. It is useful in many situations. As another example, consider a web application where administrators build form templates and then users fill out the forms. One way to model this is to populate the form builder interface FormDefinition objects, containing instances of TextFieldDefinition, CheckboxFieldDefinition, DateFieldDefinition, and so on. Then, when the form definition is complete and ready for user input, a new Form object is created, using the FormDefinition as a guide, with TextField, CheckboxField, DateField, etc. objects “inside” of it.

If we apply the Prototype Pattern to this problem, we once again do away with the definition/instance dichotomy. Instead, building a new form simply means assembling a Form object, where all of the form fields have empty or placeholder values. (This makes it exceptionally easy to show a live preview of the form as it is being built). The form is published by turning on a flag marking it as a “master” form. Whenever a user fills out the form, they are really filling out a duplicate of the master.

Observations

Design Patterns says that the Prototype Pattern is appropriate:

when a system should be should be independent of how its products are created, composed, and represented, and

when the classes to instantiate are specified at run-time, for
example, by dynamic loading; or

to avoid building a class hierarchy of factories that parallels
the class hierarchy of products; or

when instances of a class can have only one of a few different
combinations of state. It may be more convenient to install a
corresponding number of prototypes and clone them rather than
instantiating the class manually, each time with the appropriate
state.

The class-based view vs. the prototype-based view of OO represent a philosophical divide in how we model the world in software. We can learn from both points of view. But the lessons of the prototype-oriented mindset are not merely philosophical ones for users of class-based languages. The Prototype Pattern is a way to apply prototypes in a class-based system, one that can slash through complicated parallel inheritance hierarchies and provide a simple, flexible, and dynamic alternative.

Questions? Comments? Have experience implementing the prototype pattern in your own applications? Pipe up in the comments!

Oh, and do check out the article I wrote for Practicing Ruby. I had a blast metaprograming Ruby into behaving more like Self :-)

DisplayCase Gem Now Available

Avdi Grimm — Mon, 04 Jun 2012 13:00:34 +0000

When I set out to write Objects on Rails, I knew I wanted to cover the Presenter pattern. Or at least, what I thought of as the Presenter pattern. So I set out to read up on the history of Presenters in the context of Ruby on Rails applications.

The more I read, the more I realized that what I and possibly others had been calling “Presenter” was really something a bit different from the idea that Jay Fields first introduced under that name in 2006, and subsequently expanded on. Originally, Presenter was fundamentally an aggregation pattern. The canonical example is a report: you have a view in which data from numerous models is brought together into a single summary view. Rather than have a controller instantiate and/or query numerous models, you group them all into a Presenter object which represents that logical “screen” as a single aggregate object.

I won’t bore you with the details of my research. If you’re curious, here’s my Presenter reading list from OoR:

Model View Controller + Presenter? - the post that first introduced the Presenter concept.
Another Presenter Example
Presenters – An Additional layer example.
Presenter Pattern - a formalization of the pattern.
Rise, Fall, and Potential Rebirth of the Presenter Pattern. A retrospective look at the experiences Jay and others had applying Presenters to various projects.
Courtenay Gasking: Simple Presenters.
Zach Dennis: The Exceptional Presenter.
Dmytro Shteflyuk: Simplifying your Ruby on Rails code: Presenter pattern, cells plugin.
Steve Klabnick: Better Ruby Presenters. A follow-up to The Secret to Rails OO Design, referenced earlier.
Jeff Casimir: Blow Up Your Views. Jeff encoded the concepts introduced in this presentation in his Draper gem.
Martin Fowler summarizes GUI patterns. Note: this article is more concerned with rich client-side GUI patterns than web GUIs.

By contrast, what I had been using on several projects, and was eager to show people in the book, was more of a presentational decorator. Now I had a quandary: I had already drafted a whole section on them, but now I wasn’t sure what to call them. “Decorator” was too generic for the very specific kind of decorator I was describing. “Presentational decorator” didn’t exactly roll off the tongue.

The presentational pattern I came to describe as an “exhibit” in OoR has the following trademarks:

It wraps a single model instance. Not an assortment of objects.
It is a true Decorator. All unrecognized messages are passed through to the underlying object. This facilitates a gradual migration to the use of Exhibits to encapsulate presentation knowledge, since they can be layered onto models without any change to the existing views. It also enables multiple Exhibits to be layered onto an object, each handling different aspects of presentation.
It brings together a model and a context. Exhibits need a reference to a “context” object—either a controller or a view context—in order to be able to render templates as well as construct URLs for the object or related resources.
It encapsulates decisions about how to render an object. The tell-tale of an Exhibit is telling an object “render yourself”, rather than explicitly rendering a template and passing the object in as an argument.
It may modify the behavior of an object. For instance, an Exhibit might impose a scope on a Blog#entries association which only returns entries that are visible to the current user (as determined from the Exhibit’s controller context). Or it might reformat the return value of a #social_security_number method to include dashes and have all but the last four digits obscured: ***-**-5678.
There is a many-to-many relationship between model classes and exhibit classes. One generic exhibit class may apply to several different types of model. Other exhibits may be specific, not just to a model, but to a model in a particular state, or within a particular viewing context.

The more I thought about it, the clearer it seemed that while this idea wasn’t new–a number of people were already using similar constructs–it had sufficient unique traits to perhaps warrant a name of its own. And I was convinced that continuing to call it a “presenter” would just make things needlessly confusing. Hence, the term “exhibit” was born.

Since I released the book, the Exhibit idea seems to have struck a chord. I get a lot of feedback from people who say they are happily using it in their own projects. In fact, I get more positive feedback about Exhibits than about anything else in the book.

While anyone can roll their own Exhibits–that’s the point of a pattern, after all–I fully intended to release the basic Exhibit framework demonstrated in the OoR source code as open-source code. Today, thanks once again to the diligent curation of Sammy Larbi, I’m happy to announce that this code is available as the display_case gem. Of course, it’s also available on GitHub as well.

Why call it “display_case” instead of “exhibit”? Simply because it’s a pet peeve of mine to name libraries after patterns. It makes discussing them confusing–are we talking about the general pattern, or a specific library?

This post has been long enough, so I won’t go into usage here. You can read all about how to use the gem on the homepage. And if you have any questions or suggestions, please do join the Objects on Rails public discussion list!

Making Little Classes out of Big Ones (video)

Avdi Grimm — Fri, 25 May 2012 13:00:05 +0000

I recently visited the Hashrocket offices in Jacksonville, and while I was there I did a Lunch & Learn talk on the topic of of breaking down too-big classes into smaller pieces. In it I went over pros and cons of four strategies:

Breaking the class into modules
Decorators
Dynamic module extension
Object Composition

We had a nice long conversation after the talk proper, which is one of the things I like about these more informal talks.

Here’s the video:

The slides are available as well.

Decoration is best, except when it isn’t

Avdi Grimm — Tue, 31 Jan 2012 14:00:00 +0000

I think by now we all know to prefer composition over inheritance. But in a language with a lot of options, what’s the best kind of composition to use?

Composing an adventure

Consider an adventure game, with objects representing player characters.

class Character
  # ...
end

A Character can be described:

class Character
  # ...
  def describe
    puts "You are a dashing, rugged adventurer."
  end
  # ...
end

A Character can look, listen, and smell his environment:

class Character
  # ...
  def look
    list("You can see", ["a lightning bug", "a guttering candle"])
  end

  def listen
    list("You hear", ["a distant waterfall"])
  end

  def smell
    list("You smell", ["egg salad"])
  end

  def list(prefix, objects)
    objects.each do |o|
      puts "#{prefix} #{o}."
    end
  end
  # ...
end

require './decoration-vs-extension'
cohen = Character.new
cohen.describe
cohen.look
cohen.listen

You are a dashing, rugged adventurer.
You can see a lightning bug.
You can see a guttering candle.
You hear a distant waterfall.

The character can also consult all of his senses at once:

class Character
  # ...
  def observe
    look
    listen
    smell
  end
  # ...
end

require './decoration-vs-extension'
cohen = Character.new
cohen.observe

You can see a lightning bug.
You can see a guttering candle.
You hear a distant waterfall.
You smell egg salad.

Characters can have various effects conferred upon them by items, potions, etc. A simple example is a hat:

require 'delegate'
class BowlerHatDecorator < SimpleDelegator
  def describe
    super
    puts "A jaunty bowler cap sits atop your head."
  end
end

At each turn of the game, the Character object will be decorated with whatever effects are currently active, and then a user command will be performed:

require './decoration-vs-extension'
cohen = BowlerHatDecorator.new(Character.new)
cohen.describe

You are a dashing, rugged adventurer.
A jaunty bowler cap sits atop your head.

Seeing in the dark

A more interesting effect is conferred by an infravision potion. It enables your character to see in the dark.

class InfravisionPotionDecorator < SimpleDelegator
  def describe
    super
    puts "Your eyes glow dull red."
  end

  def look
    super
    look_infrared
  end

  def look_infrared
    list("You can see", ["the ravenous bugblatter beast of traal"])
  end
end

While the character is experiencing the effects of an infravision potion, his powers of observation increase:

require './decoration-vs-extension'
cohen = InfravisionPotionDecorator.new(Character.new)
cohen.describe
cohen.look

You are a dashing, rugged adventurer.
Your eyes glow dull red.
You can see a lightning bug.
You can see a guttering candle.
You can see the ravenous bugblatter beast of traal.

There’s just one little problem that crops up when the #observe method is called.

require './decoration-vs-extension'
cohen = InfravisionPotionDecorator.new(Character.new)
cohen.observe

You can see a lightning bug.
You can see a guttering candle.
You hear a distant waterfall.
You smell egg salad.

Hey, where’d that bugblatter beast go?

The Character#observe method calls #look—but since the wrapped object has no knowledge whatsoever of the InfravisionPotionDecorator, it calls the original definition of #look, not the one which also calls #look_infrared.

Now, granted, this flaw actually works out in our intrepid adventurer’s favor, since the ravenous bugblatter beast of Traal is so stupid it thinks that if you can’t see it, it can’t see you. But never mind that: it’s still a bug, and bugs must be blattered.

A solution that’s all wet

We could patch this flaw by overriding #observe as well in the decorator:

class InfravisionPotionDecorator < SimpleDelegator
  def observe
    look
    listen
    smell
  end
end

Yuck! This is the exact same implementation as in Character, just copied and pasted so that the correct implementaiton of #look will be called. Clearly this is non-DRY. But even worse, we’ve introduced a nasty variety of connascence. Every time we introduces a new Character method which calls #look, we’ll have to cull through every single effect decorator which overrides #look, adding copy-and-pasted versions of the new method so that it doesn’t accidentally ignore the effect-wrapped version. Double yuck!

Modules to the rescue

In Ruby, there is an easy solution: extend the character with a module instead of a decorator.

module InfravisionPotionModule
  def describe
    super
    puts "Your eyes glow dull red."
  end

  def look
    super
    look_infrared
  end

  def look_infrared
    list("You can see", ["the ravenous bugblatter beast of traal"])
  end
end

require './decoration-vs-extension'
cohen = Character.new.extend(InfravisionPotionModule)
cohen.observe

You can see a lightning bug.
You can see a guttering candle.
You can see the ravenous bugblatter beast of traal.
You hear a distant waterfall.
You smell egg salad.

This time the overridden method is added directly to the object via its singleton class. So even the object’s own unmodified methods get the new infravision version of #look.

Sadly, by enabling him to see the monster we have sealed our protagonists’s fate. But at least we fixed the bug!

Are decorators overrated?

So what can we learn from this? When composing objects, Is it always better to use module extension than decoration?

In a word, no. For one thing, decoration is a simpler structure to understand. Given object A wrapped in object B wrapped in object C, it’s easy to reason about how method calls will be handled. They’ll always go one-way: a method in object A will never reference a method in B or C.By contrast, method calls in a module-extended object can bounce around the inheritance heirarchy in unexpected ways.

A second consideration is that once you’ve extended an object with a module, its behavior is changed for all clients, including itself. You can’t interact with the “unadorned” object anymore. You might extend an object for your own purposes, then pass it to a third-party method which doesn’t understand the modified behavior of the object and barfs as a result.

Finally, there’s a performance penalty. While it varies from implementation to implementation, dynamically extending objects can slow down your code as a result of the method cache beign invalidated. Of course, as with all performance-related guidelines, be sure to profile before making any code changes based on this point.

Conclusion

Decoration and module extension are both viable ways to compose objects in Ruby. Which to use is not a simple black-or-white choice; it depends on the purpose of the composition.

For applications where you want to adorn an object with some extra functionality, or modify how it presents itself, a decorator is probably the best bet. Decorators are great for creating Presenters, where we just want to change an object’s “face” in a specific context.

On the other hand, when building up a composite object at runtime object out of individual “aspects” or “facets”, module extension may make more sense. Judicious use of module extension can lead to a kind of “emergent behavior” which is hard to replicate with decoration or delegation.

At least, this has been my experience. Got some experiences or opinions on decoration vs. module extension? Feel free to leave a note in the comments!

SBPP #4: method Cascades

Avdi Grimm — Mon, 26 Sep 2011 13:00:41 +0000

In Smalltalk, you can “cascade” side-effectful calls to the same object using the semicolon (;) operator. E.g.:

If I understand it correctly, the semicolon is effectively a K-combinator or “Kestrel”.

I am jealous. Sure, we have Object#tap, but that’s awfully verbose by comparison:

(I’m using multiple taps in order to exactly mimic the semantics of the Smalltalk semicolon operator in the example above.)

Let’s see if we can do better for this simple case of cascading a series of commands, while ignoring their return values.

module Cascadable class CascadeProxy < BasicObject def initialize(object) @object = object end def method_missing(*args, &block) @object.send(*args, &block) return self end end def cascade return CascadeProxy.new(self) end alias_method :k, :cascade end class Object include Cascadable end $stdout.k. print(x). print(' @ '). print(y)

Yay! That looks a lot nicer.

SBPP #3: Reversing Method

Avdi Grimm — Fri, 23 Sep 2011 13:00:55 +0000

I’m pleased to find Kent Beck shares my affinity for methods with a consistent cadence. In the next pattern I translate, he looks for a way to bring a uniform rhythm to a method that writes an object to a stream.

# Reversing Method # There is an easy solution for the specific case of writing to an # output stream. I'll put that at the end. First, I'll translate # literally into Ruby. # Example 1 class Point attr_accessor :x, :y def initialize(x, y) @x, @y = x, y end def print_on(stream) x.print_on(stream) stream.next_put_all(' @ ') y.print_on(stream) end end # Example 2 class Stream def print(object) object.print_on(self) end end class Point def print_on(stream) stream.print x stream.next_put_all ' @ ' stream.print y end end # Of course, Ruby has no such thing as "Stream". It has a conventional # notion of an 'IO-like' object, but no unifying module along the # lines of Enumerable or Comparable which is included by all IO-like # objects. More's the pity. # We could put this functionality in a module, and include it into # IO-likes as needed. We'll call it #print_obj since #print is already # taken by IO-likes. module ObjectPrinter def print_obj(object) object.print_on(self) end end class Point def print_on(io) io.print x io.print ' @ ' io.print y end end $stdout.extend(ObjectPrinter) p = Point.new(23,32) p.print_on($stdout) # However, for the specific case of handling output, Ruby has a # solution which is concise and functionally equivalent to the # Smalltalk example: class Point def print_on(io) io << x << ' @ ' << y end end puts # blank line p.print_on($stdout)

SBPP #2: Smalltalk Patterns in Ruby

Avdi Grimm — Thu, 22 Sep 2011 15:35:14 +0000

Smalltalk Best Practice Patterns continues from the introduction with a brief explanation of patterns. Some notable quotes:

About leveraging commonality: “large-scale software re-use has not proven to be the answer”. A lot of the mid-90s OO PR centered around the idea that we’d all build our apps out of reusable off-the-shelf objects. As Beck notes, this didn’t really pan out. With rare exceptions, in-process software re-use still takes the form it always did: it happens at the “library” level of granularity, not at the object level. Patterns have been a much more successful way to re-use ideas.
“By carrying along their justification, patterns avoid the problem of most “style guides” that simply prescribe solutions without discussing why or when the solution is appropriate”. Ironically, I often hear the criticism that patterns are “prescriptive, one-size-fits-all solutions”. When I hear this it makes me wonder if the person saying it has read a patterns book lately. Central to the form is a careful discussion of when the pattern makes sense, and when it doesn’t.

Once I got into the meat of the book I decided that, since I’m reading it for the Ruby Rogues book club, I should probably take a stab at translating the patterns to Ruby. You are welcome to follow my progress on GitHub: https://github.com/avdi/sbpprb. Also, feel free to fork and submit pull requests for alternate translations. There is definitely room for interpretation on some of these.

On Composed Method, this bit is key: ”keep all operations in a method at the same level of abstraction”. I hate it when I find a system that has been broken up into small methods—except that the small methods still combine high-level calls with fiddly, low-level code. Code like this has all the disadvantages of small methods (harder to follow the logic) with none of the advantages (only having to introduce a change in one place).
There are a number of construction & coercion patterns early in the book. One thought that sprung out to me in reading these is that I don’t spend enough time thinking about writing alternatives to “.new” in Ruby code. More often, I just write a fancy “#initialize” which can handle various combinations of arguments. But there’s a good argument to be made in many classes for avoiding .new and instead defining more specific forms, e.g. Point.new_from_coords, Point.new_from_polar.
That last point is relevant to Rails code. A lot of the specialized factory methods I see for testing (“Factory.create(:admin_user)”) really ought to have analogs on the original model (User.new_admin).

SBPP #1: Introduction

Avdi Grimm — Tue, 20 Sep 2011 13:00:11 +0000

The Ruby Rogues are reading Smalltalk Best Practice Patterns for next month’s book club, so I finally got around to ordering a copy. It’s high time, considering that in my experience it’s one of the most consistently recommended programming books in print.

Some notes and quotes from the introduction:

Defining patterns: “a pattern is a decision an expert makes over and over”.
Patterns in the small: “I’m constantly amazed at how even a little help cleaning up small problems reveals the source and solution of much bigger problems”.
“It is easy to get numbed to pain and frustration, or treat it as if is part of the territory”—this dovetails with a realization I had recently: my “Confident Code” talk, at its core, isn’t about clean code; it’s about joy. Programming in a conducive programming language should be pleasant. Fun. Joyful, even. Antipatterns steal joy because they add weight to every step. It’s worthwhile to periodically remember the joy of that first “a-ha!” moment in Ruby (or Smalltalk, or whatever), and figure out if and why we aren’t feeling that way anymore.
“The very act of deciding what corners to cut slows down development. Using these patterns lets you program flat out, applying patterns as fast as your fingers will go, and get results as quickly as possible”. Beck goes on to say of adopting these patterns “whole hog”: “…I spent a couple of frustrating weeks programming at less than full speed. After that, I memorized enough patterns to get back up to my old productivity, but the code I was producing was cleaner than before. After a couple more weeks, I no longer had to look up any patterns, and my productivity shot up while my code kept getting cleaner and cleaner.”

This last quote nicely sums up an observation I’ve made over the years. A lot of programmers, when evaluating a new discipline, note (correctly) that adopting it will slow them down in the short term. They then extrapolate from this short-term slowdown that it will always slow them down, and is therefore a waste of time.

Maybe it’s just good ‘ole hacker hubris: the assumption that we can fully assimilate any new knowledge in a matter of hours, and if not, it’s not worth learning. In any case, it’s a flawed mental model. New disciplines, when practiced diligently, eventually become automatic.

Your Code is My Hell

Avdi Grimm — Mon, 22 Aug 2011 13:30:26 +0000

It occurred to me recently that my experience as a Rails developer may be somewhat unique.

I often get brought in to help preexisting Ruby/Rails projects evolve and mature in a sustainable way. As a result, the vast majority of Ruby projects I’ve worked on have been well-established by the time I arrived. In fact, offhand I can only think of one commercial greenfield Ruby project I’ve participated in. All the rest have been “legacy” from my perspective, in the sense that there was a sizable codebase in production before I showed up. (I’m not counting personal and internal projects.)

I’ve realized that in this my experience may be somewhat unusual among Ruby and Rails developers. With its fast churn and startup-heavy community, a lot of Rubyists are working on projects that they started recently. My work is more in the codebases where the original programmers have moved on.

Rails’ dirty secret

In the days before I got paid to write Ruby, I worked on some legacy codebases that had histories spanning multiple decades and 100s of KLOCs. That’s a lot of opportunity for bad code to accumulate; and in some cases, the accumulations were impressive.

But here’s the dirty little secret of Rails development: the messiest, nastiest big-ball-of-mud code I have seen in my entire career has been in Ruby on Rails projects. I’ve seen Rails projects that accumulated enough technical debt and waste in two years to make 10 year-old C/C++ programs look clean and elegant by comparison. And it wasn’t just one project. I’ve seen it over and over.

In a way I think this is a testament to the power of the platform. If you’re getting a 500 error in a Rails app, you can keep adding kludge after kludge and hitting “reload” until it works. No need to ever write a test or refactor. In languages and frameworks with a slower turnaround time, this kind of tweak-it-till-it-works workflow is simply impractical. Ruby on Rails has an impressively low barrier to fiddling.

Unfortunately, as a result a lot of projects I come to on have hit what I think of as the productivity crash. At some point the cumulative effect of all those little shortcuts catches up with the development team, and changes that would once have taken a day start taking two weeks as all the dependencies and unintended consequences are sorted out.

As a somewhat ranty aside: this is also the point where, often, original members of the team start moving on to bigger and better things. Meanwhile the crew that inherited the codebase is left to field questions from management about why they can’t seem to push out changes nearly as fast as the old team. The new team is confronted with the problem of getting the codebase under better test coverage and a little more modularized before they can ramp velocity back up; thus perpetuating the notion among the business types that testing and refactoring just slows things down. And/or that the original team were some kind of wizards.

Okay, rant over.

But Rails is different!

Rails developers are sometimes accused of being arrogant and judgmental. I’m not sure how true this is; I don’t see it all that much, but maybe I’m too close to the community and/or arrogant and judgemental myself to be a fair observer.

What I do see is a kind of “Rails exceptionalism”. Remember back in the first dot-com boom, when some economists were saying that no, this time it was different, the Internet had changed the game this time the markets would just keep going up and up? The phenomenon I see is similar in spirit. it’s a belief, perhaps not fully conscious, that Ruby on Rails development is somehow different, and not subject to the forces affecting other software projects.

Here are a few examples, just to give you an idea of what I’m talking about:

“Design Patterns are a Java thing. In Ruby you just write code.”
“The warnings Ruby produces are dumb; just disable them.”
“Sure they aren’t technically Unit Tests, but isolating objects turned out to be kind of hard and besides nobody else is doing it.”
“Monkeypatching is frowned on in other languages, but in Ruby it’s fine. The downsides almost never materialize.”
“Stuff like the Law of Demeter isn’t really as important in Ruby code”
“Dividing methods into private and public is for control freaks, you don’t need it in Ruby”
“That’s only a code smell when it’s in Java code”
“That’s only a problem in large projects” (implying that this project will never become large).

I also see a fair amount of project or subsystem-level exceptionalism: “I know they say classes shouldn’t be this big, but for this class it just makes sense for all of that stuff to be in one place”.

Welcome to Lilliput

The truth is, Ruby on Rails projects are exceptional in a way: they are really small. In James Gray’s terrific keynote at Lone Star Ruby Conf this past week, he mentioned “huge projects” of 40+ KLOC. That gave me a smile, because the first two Rails projects I was ever paid to work on were 50KLOC and 70KLOC, respectively. And while that may seem like a lot of code, that’s small by industry standards.

There are a few reasons for this. Ruby is a more expressive language than, say, Java, so to some degree Rails projects will always be smaller than equivalent projects in higher-ceremony languages.

It’s also possible that Rails programmers have embraced the wisdom of breaking systems many, small, intercommunicating apps. I’d like to believe this, but experience suggests this strategy has seen only spotty uptake.

No, I think the biggest reason for the diminutive nature of Rails apps is also the most obvious: they are all pretty young. It’s a young framework, and there’s a lot of churn in this community. A Rails app that lasts three years is ancient.

I think it’s safe to say that this situation won’t last. We’re going to see larger and larger codebases. And here’s a not-very-daring prediction: a lot of projects are going to hit the very same architectural roadblocks that Lisp, Smalltalk, Pascal, C++, and Java projects hit before them.

You are not a special snowflake

It’s funny reading programming literature from the 80s. Dynamic, object-oriented systems navigating the transition from “small” to “medium-sized”. Sound familiar?

Every revolutionary believes his revolution is special, and won’t devolve into the partisan bickering and venal bureaucracy that the last revolution led to. And it’s easy to believe at first. Everyone’s excited and eager to help; the problems are relatively small; and the marketing drones haven’t latched onto the movement yet.

The truth is, the problem you are solving probably isn’t as special as you think it is. And those byzantine patterns you thought were a relic of a bygone age were invented by people using languages surprisingly similar to Ruby.

Don’t panic

Relax. I’m not here to tell you that the last few years were all just a lovely dream, and you’re really still strapped to a chair in the Ministry of UML.

Ruby is still a wonderful language, and the terrific thing about it is that it adapts to large-system design patterns remarkably easily, and with very little ceremony. Dependency Injection? It’s a one-liner. Object delegation and composition? Piece of cake. Contrary to misconceptions, Ruby doesn’t obviate solid design patterns and SOLID principles; what it does is make them very easy to express. In fact, the ease of expressing robust architectural styles was what attracted some of us early-adopters to the language in the first place.

Just please, do me a favor: before you tell me that Ruby and Rails doesn’t need any of this discipline, have a chat with the guy or gal who is still maintaining the first Rails app you worked on.

Fowler on Rails

Avdi Grimm — Wed, 27 Jul 2011 18:35:17 +0000

Projects using Ruby on Rails often lack strong distinctions in two main areas:

The model/record conflation: Seeing “models” as strictly DB-backed resources.
The view/template conflation: failing to draw a line between view objects and HTML templates.

The conflations are encouraged by Rails’ design decisions. When choosing which enterprise design patterns to translate into code, the Rails developers chose Active Record (a relatively thin, one-to-one take on the ORM idea), and Template View.

I am not faulting them for this decision. These were both thoroughly pragmatic decisions which mapped well to the kind of applications that Rails was aimed at. By encoding these opinions into the framework and covering them with a sweet coating of convention-over-configuration, Rails saved thousands of projects from pattern analysis paralysis.

But now Rails applications are maturing, and a lot of developers are starting to realize that these patterns may not scale so well to more and more complex applications. When figuring out how to move forward, we could do much worse than to consult the same book that laid the blueprints for Rails’ architecture, Patterns of Enterprise Application Architecture.

Here’s Martin Fowler on Domain Models:

An OO domain model will often look similar to a database model, yet it will still have a lot of differences. A Domain Model mingles data and process, has multivalued attributes and a complex web of associations, and uses inheritance.

As a result I see two styles of Domain Model in the field. A simple Domain Model looks very much like the database design with mostly one domain object for each database table. A rich Domain Model can look different from the database design, with inheritance, strategies, and other [Gang of Four] patterns, and complex webs of interconnected objects. A rich Domain Model is better for more complex logic, but is harder to map to the database. A simple Domain Model can use Active Record, whereas a rich Domain Model requires Data Mapper.

Note that Fowler is referring to the Active Record and Data Mapper design patterns, not to the Ruby libraries those patterns inspired. There is a correspondence, though: the DataMapper library, like the pattern it is based on, puts a higher value on decoupling the domain model from the database schema.

Now on to views. Here’s Fowler talking about Two Step Views, an alternative to the Template View pattern:

You may… want to want to make global changes to the appearance of the site easily, but common approaches using Template View or Transform View make this difficult because presentation decisions are often duplicated across multiple pages or transform modules. A global change can force you to change several files.

Two Step View deals with this problem by splitting the transformation into two stages. The first transforms the model data into a logical presentation without any special formatting; the second converts that logical presentation with the actual formatting needed.

I do a lot of two-step view processing in my projects. I haven’t had a chance to take a close look at, but I think this process is also what Jeff Casimir is aiming at with Draper, and I support and applaud his efforts.

And that’s all I had to say about that… I just wanted to post those quotes in case anyone else found them noteworthy.