Feature envy & inappropriate intimacy

Feature envy is a method more interested in another object’s data than its own. The diagnostic is mechanical: count the fields the method reads. If most of them belong to one other object, the method is envious of that object — it wants to be a method on it.

class InvoicePrinter {
  // envious: every field it touches belongs to `order`, none to `this`
  amountDue(order: Order): number {
    const subtotal = order.lineItems
      .reduce((s, li) => s + li.price * li.qty, 0);
    const tax = subtotal * order.taxRate;
    const shipping = order.shippingRegion === "intl" ? 25 : 5;
    return subtotal + tax + shipping - order.couponPercent * subtotal;
  }
}

amountDue reads lineItems, taxRate, shippingRegion, couponPercent — four pieces of Order’s state — and nothing of InvoicePrinter. The behaviour and the data have been separated, and the join between them is now a public surface Order has to expose. The fix is to move the method next to the data it envies.

The cure for feature envy is Move Method: relocate behaviour to the data it envies. Put amountDue on Order. Now it reads its own fields, Order can keep them private, and InvoicePrinter asks one question instead of four.

class Order {
  // behaviour now sits on the data it uses
  amountDue(): number {
    const tax = this.subtotal() * this.taxRate;
    const shipping = this.shippingRegion === "intl" ? 25 : 5;
    return this.subtotal() + tax + shipping - this.couponPercent * this.subtotal();
  }
  private subtotal(): number {
    return this.lineItems.reduce((s, li) => s + li.price * li.qty, 0);
  }
}

class InvoicePrinter {
  print(order: Order): string {
    return `Total: ${order.amountDue().toFixed(2)}`; // one call, zero envy
  }
}

Coupling dropped measurably: InvoicePrinter’s dependency on Order shrank from four fields to one method. taxRate, couponPercent, and shippingRegion can now be private — the rule that combines them lives with them. This is tell-don’t-ask: tell the order to compute its due amount; don’t ask it for its guts and do the arithmetic outside.

Inappropriate intimacy is feature envy made mutual: two classes reaching into each other’s internals. Feature envy is one-directional — a method wants another object’s data. Intimacy is bidirectional and structural — A reads/writes B’s private state and B reads/writes A’s. They become a single tangled unit pretending to be two classes.

class Account {
  balance = 0;
  history: Transaction[] = [];
}

class Transaction {
  apply(acct: Account) {
    acct.balance += this.amount;        // mutating Account's field
    acct.history.push(this);            // reaching into Account's internals
  }
}

class Account2 {
  reverse(tx: Transaction) {
    this.balance -= tx.amount;          // reading Transaction's field
    tx.reversed = true;                 // mutating Transaction's field
  }
}

Each class assumes the other’s exact shape and writes through it. Change Account’s balance representation (cents? a money type? an event log?) and Transaction.apply breaks; change Transaction’s fields and Account.reverse breaks. You cannot reason about, test, or evolve either one alone. The intimacy is the coupling.

Restore encapsulation: give each class a boundary, or extract the shared concept. Two moves dissolve intimacy. First, replace cross-object field access with intention-revealing methods, so neither class depends on the other’s internals — only on a small named interface:

class Account {
  private balance = 0;
  private history: Transaction[] = [];
  post(tx: Transaction): void {          // Account owns its own mutation
    this.balance += tx.signedAmount();
    this.history.push(tx);
  }
}

Transaction now exposes signedAmount() and Account owns every write to its own fields; neither reaches across. Second move, when the entanglement is because they share a concept neither owns (here: posting a balance change with its audit trail), extract that concept into its own type — a Posting or Ledger that both collaborate with cleanly. The senior heuristic: if moving a method just shifts the envy in the other direction, the missing element is usually a third object that doesn’t exist yet.

Failure mode: don’t relocate orchestration that legitimately spans several objects. The rule “move behaviour to the data it envies” assumes the behaviour belongs to one object’s data. But some methods touch many objects’ fields by design — they coordinate a workflow: a checkout that reads the Cart, charges via PaymentGateway, decrements Inventory, and writes an Order. That method looks envious of all four, yet it belongs to none of them. It is a use-case / service, and orchestration belongs at a higher level than any single data object.

// Legitimate orchestration — NOT feature envy. Do not jam this into Cart or Order.
class CheckoutService {
  async checkout(cart: Cart, payment: PaymentGateway, inventory: Inventory): Promise<Order> {
    const total = cart.total();               // each object does its own work...
    await payment.charge(total);              // ...the service only sequences them
    inventory.reserve(cart.items());
    return Order.from(cart);
  }
}

The tell: a service sequences calls to objects that each do their own work (cart.total(), payment.charge()), whereas envy does another object’s work for it (reading cart.taxRate and computing tax outside the cart). If you “fix” the orchestrator by pushing it inside Cart, you give Cart knowledge of payments and inventory it should never have — you traded a false smell for real coupling. Move behaviour to data; leave coordination above the data.