I’ve been really enjoying James Edward Gray II’s Rubies in the Rough articles. Every couple of weeks, he publishes something that is guaranteed to get me thinking about some aspect of coding I hadn’t considered before.

His  latest article is part I of an exploration of an algorithm for the Hitting Rock Bottom problem posed by Gregory Brown & Andrea Singh. At its core, the problem asks you to simulate pouring water into a 2D container, filling it using a simple set of rules.

As I was coding up my solution, I found I had code like

case 
  when cave.cell_below == " "        then cave.move_down
  when cave.cell_to_the_right == " " then cave.move_right
  # ...
  else
    cave.move_up
    cave.move_left until cave.cell == "~"
    # ...

Here ” “ is a cell containing air, and ”~” a watery cell. So clearly we should create some named constants for that:

AIR   = " "
WATER = "~"

case 
  when cave.cell_below == AIR        then cave.move_down
  when cave.cell_to_the_right == AIR then cave.move_right
  # ...
  else
    cave.move_up
    cave.move_left until cave.cell == WATER
    # ...

But it occurred to me that we could use Ruby’s singleton methods to give AIR and WATER a little smarts:

WATER = "~"
AIR   = " "
[WATER, AIR].each do |content|
  def content.in?(cell)
    cell == self
  end
end

# ...
case 
when AIR.in?(cave.cell_below)        then cave.move_down
when AIR.in?(cave.cell_to_the_right) then cave.move_right
# ...
else
  # ...
  cave.move_left until WATER.in?(cave.cell) if AIR.in?(cave.cell)

Now you could argue that the cave object should do this: cave.watery?, or that the individual elements in the cave should be objects that know their moisture content, rather than simply characters. I don’t agree with the first (simply because the cave is the container, and the water/air is the separate stuff that goes into that container). I have a lot of sympathy for the second, and I’d probably end up there given a sufficiently large nudge during a refactoring. 

WATER = "~"
AIR   = " "
[WATER, AIR].each do |content|
  def content.in?(cell)
    cell == self
  end
end

# ...
case 
when AIR.in?(cave.cell_below)        then cave.move_down
when AIR.in?(cave.cell_to_the_right) then cave.move_right
# ...
else
  # ...
  cave.move_left until WATER.in?(cave.cell) if AIR.in?(cave.cell)  

But, for the problem at hand, simply decorating the two constants with a domain method seems to result in code that is a lot more readable. It isn’t a technique I’d used before, so I thought I’d share.

(And remember to check out Rubies in the Rough…)