# Policy interface

A parking lot bills a stay by vehicle type. The version you write in minute three puts the rates
in a `switch` inside `ExitGate.feeMinor`. On the afternoon it is written that is the right call:
one class, nothing to follow.

Then finance replaces the tariff. First hour free, standard rate for hours two and three,
long-stay rate from the fourth. You are back inside `ExitGate.java`, rewriting a method you had
already tested.

Measured on the pair in `contrast/`: design A absorbs that change in **26 lines** in one
pre-existing file, `a/ExitGate.java`. Design B asks an injected `PricingPolicy` and absorbs it in
**2** — a new file, `TieredPricing.java`, plus the one line that names today's tariff. Both
numbers come from `measureChange()` in `server/lib/diff.mjs`, the function D4 is scored from.
`corpus/parking-lot/curveballs/02-tiered-pricing/budget.json` records `reference_diff: 2` for the
same change at full scale.

The line count is not the whole difference. After A's edit, last month's tariff is gone. Against
B, `new ExitGate(new FlatHourlyPricing())` still compiles and still bills 8000, which is what
auditing July needs.

So extract when a second implementation exists, when the requirements name one, or when the
interviewer has said that rule moves. One implementation with no second in sight scores *lower*:
D3 level 3 asks for a minimal seam set, and `over-engineered` routes back to `when-not.md`.
Pulling the policy out afterwards cost 32 lines in one file, measured, base suite green
throughout — a one-time price, paid when you know you need it.
