In this series we’re exploring the problem “a player can use a weapon, a wizard is a kind of player, a staff is a kind of weapon, but a wizard can only use a staff”. The best solution we’ve come up with so far is to throw a conversion violation at runtime if the developer makes a mistake, which seems less than optimal.
Continue reading →

A common problem I see in object-oriented design is:

• A wizard is a kind of player.
• A warrior is a kind of player.
• A staff is a kind of weapon.
• A sword is a kind of weapon.
• A player has a weapon.

But before we get into the details, I just want to point out that I am not really talking about anything specific to the fantasy RPG genre here. Everything in this series applies equally well to Papers and Paychecks, but wizards and warriors are more fun to write about, so there you go.

OK, great, we have five bullet points so let’s write some classes without thinking about it! What could possibly go wrong?

Continue reading →

Occasionally I’m asked to review code that has a lot of repetition in it. Like, for instance, someone is writing a function memoizer:

static Func<A, R> Memoize<A, R>(this Func<A, R> function)
{
  var cache = new Dictionary<A, R>();
  return argument =>
  {
    R result;
    if (!cache.TryGetValue(argument, out result))
    {
      result = function(argument);
      cache[argument] = result;
    }
    return result;
  };
}

And then they will write remarkably similar code for functions of two arguments, functions of three arguments, functions of four arguments, and so on. “I want my code to be DRY; how can I avoid repeating myself?” is what the developer asking for review usually says.

Continue reading →

Gareth Wilson from Fog Creek interviewed me the other day for their series on the lives of developers; we talked about playing Dam Buster on the Commodore PET and typing in programs in WATCOM VI and all kinds of stuff. Thanks Gareth, I enjoyed it very much. You can read the interview here.