Introduce parameter object

The trigger is a data clump or a long parameter list — the same fields traveling together. A clump is two or more values that keep appearing as a set: (startDate, endDate), (x, y), (amount, currency), (host, port, protocol). The tell is mechanical: if you delete one of them, the rest stop making sense. A long parameter list is the same disease at a single call site — five, six, eight positional arguments where the reader can no longer tell which is which.

// before: the (start, end) clump rides through every function, plus boolean noise
function priceStay(
  start: Date,
  end: Date,
  ratePerNight: number,
  taxRate: number,
  includeCleaning: boolean,
  isWeekendPremium: boolean,
): number { /* ... */ }

book(start, end, 120, 0.2, true, false); // which boolean is which?

The positional booleans are unreadable and the (start, end) pair has appeared in four functions already. Both are signals, not noise — they tell you a concept is missing.

Do it in safe steps, staying green the whole way. Introduce Parameter Object is a mechanical refactor with a defined sequence, and you keep the tests passing after each step rather than rewriting in one leap:

1. Create the new type with the clumped fields. Don’t change any signatures yet.
2. Add the object as a new parameter to the target function, keeping the old ones; have the body read from the new object. Tests still green.
3. Update one caller to pass the object. Green. Then the next caller. Green.
4. Once every caller passes the object, delete the now-unused individual parameters.
5. Move behavior that operated on the clumped values onto the new type (next step).

type DateRange = { readonly start: Date; readonly end: Date };

function priceStay(range: DateRange, rate: RateCard): number { /* ... */ }

Each step is reversible and verified, so a mistake is caught one move from where you made it — that is the whole point of refactoring under tests rather than via a big-bang rewrite.

The real payoff: behavior and validation gravitate to the new object. Once DateRange exists, every “is this range valid?” / “how many nights?” / “do these overlap?” check that was duplicated across callers has an obvious home — on the type. Martin Fowler calls this the deeper reason for the refactor: the new object becomes a magnet that attracts the behavior scattered around it.

class DateRange {
  constructor(readonly start: Date, readonly end: Date) {
    if (end < start) throw new RangeError("end before start");
  }
  get nights(): number {
    return Math.round((+this.end - +this.start) / 86_400_000);
  }
  overlaps(other: DateRange): boolean {
    return this.start < other.end && other.start < this.end;
  }
}

The end < start validation now happens once, at construction — so no downstream function can ever receive an inverted range. nights is computed in one place instead of being re-derived (with off-by-one bugs) in pricing, calendar, and reporting. This is the senior point: a parameter object doesn’t just shorten signatures, it names a missing concept and gives the related logic a place to live, which kills a whole class of duplication.

Whole-object: pass the object you already have instead of unpacking it. A close cousin: when a caller pulls several fields out of an existing object only to pass them as separate arguments, pass the object itself. This shrinks the parameter list, decouples the callee from the caller’s field layout, and lets the callee ask the object for more later without a signature change.

// before: caller unpacks, callee re-couples to the field names
const within = isWithinBudget(quote.low, quote.high, order.total);

// after: pass the whole object; the rule moves where it belongs
const within = quote.contains(order.total);

When NOT to: if the callee genuinely needs only one field, passing the whole object over-couples it to a type it barely uses — prefer the single value (this is the Law of Demeter / interface-segregation tension). Whole-object is right when the callee uses several fields or when “the rule lives on the object” reads more naturally than “the caller computes the rule.”