Extract class

The data clump and the method cluster tell you where the seam is — you don’t invent it, you read it. Extract Class is Single Responsibility Principle applied retroactively, and the signal that two responsibilities have fused is structural, not aesthetic. Look for a data clump: a set of fields that always appear together (areaCode + number, or street + city + zip). Then look at which methods touch only that subset of fields and ignore the rest of the class. That overlap — fields that cluster, methods that serve only the cluster — is the seam.

class Person {
  name: string;
  // ── the data clump: these three always move together ──
  areaCode: string;
  number: string;
  // ── the method cluster: it only ever touches the clump above ──
  phoneAsString(): string { return `(${this.areaCode}) ${this.number}`; }
}

If a candidate “responsibility” has data but no methods that exclusively serve it, or methods but no shared data, you don’t have a class waiting to come out — you have something smaller (a moved method, a renamed field). The seam has to show up in both dimensions before extraction pays.

Create the new class empty and link it — the first move changes nothing observable. Begin with a no-op step: introduce TelephoneNumber and give Person an instance of it. At this point the old fields still exist; nothing has moved. Run the tests — they must stay green, because you have added a back-reference and changed no behaviour. This empty shell is your safety scaffold: every subsequent move is now a delegation, swappable one field and one method at a time.

class TelephoneNumber {} // empty on purpose

class Person {
  name: string;
  areaCode: string;
  number: string;
  private telephoneNumber = new TelephoneNumber(); // linked, unused — tests still green
  phoneAsString(): string { return `(${this.areaCode}) ${this.number}`; }
}

The discipline here is that “Extract Class” is not one edit; it is a named refactoring made of smaller named refactorings (Move Field, Move Method). Doing it atomically — cut everything, paste into the new file, fix the compiler errors — is how a behaviour-preserving move turns into an accidental behaviour change you discover in production.

Move fields one at a time, replacing each with a delegating accessor, tests green after every move. Take areaCode. Add it to TelephoneNumber with a getter/setter, then make Person.areaCode delegate to this.telephoneNumber. The field’s storage has moved; its public surface on Person is unchanged, so callers and tests don’t notice. Repeat for number.

class TelephoneNumber {
  private _areaCode = "";
  get areaCode() { return this._areaCode; }
  set areaCode(v: string) { this._areaCode = v; }
}

class Person {
  // storage now lives in TelephoneNumber; Person just forwards
  get areaCode() { return this.telephoneNumber.areaCode; }
  set areaCode(v: string) { this.telephoneNumber.areaCode = v; }
  phoneAsString(): string { return `(${this.areaCode}) ${this.number}`; }
}

The reason to delegate rather than rip the field out is reference safety. You may not know every caller of person.areaCode. The delegating accessor keeps them all working while the data relocates, so you can move references in a later, separate pass instead of all at once under compiler pressure.

Move the methods to the data, then move callers off Person’s forwarders and delete them. Now phoneAsString() reads only data that lives in TelephoneNumber, so it belongs there. Move it. Person.phoneAsString() becomes a one-line delegate, then — once callers are updated to ask the telephone number directly — you delete the delegate. This is the payoff move: behaviour has migrated to its data, which is the whole point. A class is cohesive when its methods and the data they use sit together.

class TelephoneNumber {
  areaCode = "";
  number = "";
  toString(): string { return `(${this.areaCode}) ${this.number}`; }
}

class Person {
  name = "";
  telephoneNumber = new TelephoneNumber();
  // delegate kept only until callers move; then deleted
  phoneAsString(): string { return this.telephoneNumber.toString(); }
}

When the last caller of a forwarder is gone, the forwarder goes too. The end state is two classes that each have a single reason to change: change the phone format and you touch TelephoneNumber; change a person rule and you touch Person. Crucially, TelephoneNumber carries behaviour (formatting, and now validation can live there too) — it is not a struct.