Завистливые функции и неуместная близость

Завистливая функция — это метод, которому данные чужого объекта интереснее своих собственных. Диагностика механическая: посчитай поля, которые метод читает. Если большинство из них принадлежат одному другому объекту, метод завидует этому объекту — он хочет быть методом на нём.

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 читает lineItems, taxRate, shippingRegion, couponPercent — четыре куска состояния Order — и ничего от InvoicePrinter. Поведение и данные разделены, а стык между ними теперь стал публичной поверхностью, которую Order обязан выставить наружу. Лечение — переместить метод к данным, которым он завидует.

Лекарство от зависти — перемещение метода (Move Method): перенеси поведение к данным, которым оно завидует. Помести amountDue на Order. Теперь он читает свои поля, Order может держать их приватными, а InvoicePrinter задаёт один вопрос вместо четырёх.

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
  }
}

Связанность измеримо упала: зависимость InvoicePrinter от Order сжалась с четырёх полей до одного метода. taxRate, couponPercent и shippingRegion теперь могут стать приватными — правило, которое их объединяет, живёт вместе с ними. Это говори, не спрашивай (tell-don’t-ask): скажи заказу вычислить сумму к оплате; не выпрашивай его потроха и не считай арифметику снаружи.

Неуместная близость — это взаимная завистливая функция: два класса лезут во внутренности друг друга. Зависть однонаправленна — метод хочет данные чужого объекта. Близость двунаправленна и структурна — A читает/пишет приватное состояние B, а B читает/пишет приватное состояние A. Они становятся единым спутанным узлом, притворяющимся двумя классами.

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
  }
}

Каждый класс рассчитывает на точную форму другого и пишет сквозь неё. Поменяй представление balance в Account (центы? денежный тип? журнал событий?) — и Transaction.apply ломается; поменяй поля Transaction — и Account.reverse ломается. Ни о том, ни о другом нельзя рассуждать, тестировать или развивать поодиночке. Близость и есть связанность.

Восстанови инкапсуляцию: дай каждому классу границу или выдели общую концепцию. Близость растворяют два хода. Первый — замени межобъектный доступ к полям методами, раскрывающими намерение, чтобы ни один класс не зависел от внутренностей другого — только от маленького именованного интерфейса:

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 теперь выставляет signedAmount(), а Account владеет каждой записью в свои поля; никто не лезет через границу. Второй ход — когда спутанность возникает из-за общей концепции, которой не владеет никто (здесь: проведение изменения баланса вместе с его аудиторским следом), выдели эту концепцию в собственный тип — Posting или Ledger, с которым оба сотрудничают чисто. Senior-эвристика: если перемещение метода просто сдвигает зависть в другую сторону, недостающий элемент обычно — третий объект, которого ещё не существует.

Режим отказа: не переноси оркестрацию, законно охватывающую несколько объектов. Правило «перемести поведение к данным, которым оно завидует» предполагает, что поведение принадлежит данным одного объекта. Но некоторые методы трогают поля многих объектов по замыслу — они координируют рабочий процесс: оформление заказа, которое читает Cart, списывает через PaymentGateway, уменьшает Inventory и пишет Order. Такой метод выглядит завистливым ко всем четырём, но не принадлежит ни одному. Это сценарий использования / сервис, и оркестрация принадлежит уровню выше любого отдельного объекта данных.

// 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);
  }
}

Признак: сервис выстраивает в последовательность вызовы к объектам, каждый из которых делает свою работу (cart.total(), payment.charge()), тогда как зависть делает работу чужого объекта за него (читает cart.taxRate и считает налог снаружи корзины). Если «починить» оркестратор, запихав его внутрь Cart, ты дашь Cart знание о платежах и складе, которого у него быть не должно — ты обменяешь ложный запах на настоящую связанность. Перемещай поведение к данным; оставляй координацию над данными.