Lab

Template method

TEMPLATE-METHOD-101 Easy · Build ~15 min

The boulder reset reopens after a failed inspection

The gym resets rope routes and boulders with two routines written a year apart. A refactor started moving them into one shared reset: RouteReset declares the steps (strip, set, inspect), and RopeReset and BoulderReset exist, but the steps were never moved into them, so each still hands the whole reset to its old routine. Meanwhile the boulder routine has drifted: it notes a failed inspection and reopens the boulder anyway.

A boulder with loose bolts reopens to the public. And the next route type the gym adds (a speed wall is planned) gets no reset at all, or a third copy of the routine to drift.

Reproduce

Run new BoulderReset().reset({ name: "Cave", problems: ["bolts"] }): it should stop at the inspection and stay closed. Today it ends “inspect: loose bolts > reopen”.

Acceptance criteria

One reset owns the order for every route type: close, strip, set, inspect, then reopen.
A failed inspection keeps any route closed, whatever its type, and the line names the problem.
Rope routes and boulders supply only their own steps: rope routes strip and set holds and quickdraws and check bolts then anchors; boulders strip and set holds, place pads, and check bolts then pads.
A route type the gym adds later (the checker brings a speed wall) gets the whole reset by supplying its three steps.

Check work runs these cases against your code once you sign in.

Not run:A boulder with loose bolts stays closed
new BoulderReset().reset({ name: "Cave", problems: ["bolts"] })
Not run:A boulder missing pads stays closed
new BoulderReset().reset({ name: "Slab", problems: ["pads"] })
Not run:A safe boulder reopens
new BoulderReset().reset({ name: "Roof", problems: [] })
Not run:Boulders have no anchors to check
new BoulderReset().reset({ name: "Cave", problems: ["anchors"] })
Not run:A safe rope route reopens
new RopeReset().reset({ name: "Arete", problems: [] })
Not run:A rope route with worn anchors stays closed
new RopeReset().reset({ name: "Arete", problems: ["anchors"] })
Not run:Bolts are checked before anchors
new RopeReset().reset({ name: "Dihedral", problems: ["anchors", "bolts"] })
Not run:A new route type gets the whole reset
new CheckSpeedReset().reset({ name: "Lane 1", problems: [] }) // the checker’s own speed-wall route type
Not run:A new route type stays closed on its own failed check
new CheckSpeedReset().reset({ name: "Lane 2", problems: ["timer"] }) // the checker’s own speed-wall route type
Not run:A rope route with a replaced inspection follows that inspection
new CheckRopeReset().reset({ name: "Arete", problems: [] }) // the checker’s rope route, with its own inspection

Notes

Each case prints the reset’s line: the route’s name, then each step in order, ending “reopen” or “inspect: <problem> > stays closed”.
Keep the names and signatures of RouteReset (Go: Reset and ResetSteps) and of the steps; the checker defines route types of its own against them, and one of them replaces a rope route’s inspection. In TypeScript keep the steps protected.
Boulders have no anchors, and rope routes have no pads: a problem a route type doesn’t check doesn’t stop it.

Hints

Reference answerTry the cases first

type Route = { name: string; problems: string[] };

// The reset every route goes through. The order, and the rule that a
// failed check keeps the route closed, live here and nowhere else.
abstract class RouteReset {
  protected abstract strip(route: Route): string;
  protected abstract set(route: Route): string;
  // The problem the inspection found, or null when the route is safe.
  protected abstract inspect(route: Route): string | null;

  // The template method.
  reset(route: Route): string {
    const done = `${route.name}: close > ${this.strip(route)} > ${this.set(route)}`;
    const problem = this.inspect(route);
    if (problem) return `${done} > inspect: ${problem} > stays closed`;
    return `${done} > inspect > reopen`;
  }
}

class RopeReset extends RouteReset {
  protected strip(route: Route): string {
    return 'strip holds, draws';
  }

  protected set(route: Route): string {
    return 'set holds, draws';
  }

  protected inspect(route: Route): string | null {
    if (route.problems.includes('bolts')) return 'loose bolts';
    if (route.problems.includes('anchors')) return 'worn anchors';
    return null;
  }
}

class BoulderReset extends RouteReset {
  protected strip(route: Route): string {
    return 'strip holds';
  }

  protected set(route: Route): string {
    return 'set holds, place pads';
  }

  protected inspect(route: Route): string | null {
    if (route.problems.includes('bolts')) return 'loose bolts';
    if (route.problems.includes('pads')) return 'missing pads';
    return null;
  }
}

The shared reset now owns everything the two routines repeated: the order and, above all, what a failed inspection means. Each route type supplies only what it knows: its own strip and set, and which problems its inspection looks for. The boulder bug was never in a step; it was in the copied sequence around them, and with one sequence it cannot come back for any route type, including ones written later, which is what the checker’s speed wall shows. The checker’s rope route replaces only the inspection and stays closed on its own verdict, which only works when RopeReset goes through the shared reset rather than an old routine. In Go the sequence is a function receiving the steps, so there is no reset to override; in TypeScript and Rust a type could still override reset, which is the next two levels’ business.

Sign in to run your code

Read the brief and the starter here. With a free account you can edit it, run the sample, step through it and check your work, and your progress is kept.

type Route = { name: string; problems: string[] };

// The gym's two reset routines, written a year apart.
function resetRope(route: Route): string {
  const done = `${route.name}: close > strip holds, draws > set holds, draws`;
  if (route.problems.includes('bolts')) {
    return `${done} > inspect: loose bolts > stays closed`;
  }
  if (route.problems.includes('anchors')) {
    return `${done} > inspect: worn anchors > stays closed`;
  }
  return `${done} > inspect > reopen`;
}

// Written later, for the bouldering wall.
function resetBoulder(route: Route): string {
  const done = `${route.name}: close > strip holds > set holds, place pads`;
  let inspected = 'inspect';
  if (route.problems.includes('bolts')) inspected = 'inspect: loose bolts';
  else if (route.problems.includes('pads')) inspected = 'inspect: missing pads';
  return `${done} > ${inspected} > reopen`;
}

// The shared reset, started in a refactor and not finished.
abstract class RouteReset {
  protected abstract strip(route: Route): string;
  protected abstract set(route: Route): string;
  // The problem the inspection found, or null when the route is safe.
  protected abstract inspect(route: Route): string | null;

  // Not written yet: each kind of route still overrides it with its old routine.
  reset(route: Route): string {
    return `${route.name}: not written yet`;
  }
}

class RopeReset extends RouteReset {
  // The steps are not moved here yet.
  protected strip(route: Route): string {
    return '';
  }

  protected set(route: Route): string {
    return '';
  }

  protected inspect(route: Route): string | null {
    return null;
  }

  // Until the refactor is done: the old routine.
  override reset(route: Route): string {
    return resetRope(route);
  }
}

class BoulderReset extends RouteReset {
  // The steps are not moved here yet.
  protected strip(route: Route): string {
    return '';
  }

  protected set(route: Route): string {
    return '';
  }

  protected inspect(route: Route): string | null {
    return null;
  }

  // Until the refactor is done: the old routine.
  override reset(route: Route): string {
    return resetBoulder(route);
  }
}