It's true: There is nothing less fun than chasing injected dependencies around from place to place in the code, only to discover that they all boil down to one line that you could have just... read.
Skimming through this essay, it looked as if the second half might be more convincing than the first, because there the logic being refactored was significantly hairier than one line.
The second half of this post made me think about _Style: Toward Clarity And Grace_, the (geekiest ever) writing book Richard Gabriel recommends (and it is great). The first fifth of the book does little else but rail against "nominalization", which is the bad writing habit of turning verbs into nouns, which abets flabby passive voice writing.
Isn't that exactly what Steve's doing here?
Combining the flexibility of Ruby with one of my favorite patterns from "Working Effectively with Legacy Code," we can take complex computations and turn them into objects.
AAAGH! BEES!
Look at Norvig code. I'm struck by how he just gets to the point. "Here's how I'm modeling my data. Here's a few functions that work with the model: whack, whack, whack! Here's 'main'. Boom, I solved Soduku."
"TurnaroundCalculator" doesn't even need state. Why is it a class with a bunch of private methods? Sure, this code doesn't belong in an AR model. So stick it in a function!
Skimming through this essay, it looked as if the second half might be more convincing than the first, because there the logic being refactored was significantly hairier than one line.