Цепочки сообщений и посредник

Цепочка сообщений связывает вызывающего со всем путём, а не только с конечной точкой. Когда код читается как a.getB().getC().getD(), вызывающий зашил форму графа: что A отдаёт B, что B отдаёт C, что C отдаёт D. Каждый промежуточный тип теперь часть контракта вызывающего на этапе компиляции, хотя вызывающему нужно было лишь конечное значение.

// Вызывающий «знает» Order → Customer → Address → string
const city = order.getCustomer().getAddress().getCity();

Радиус поражения равен длине цепочки. Поменяй любое звено — переименуй getAddress, сделай Customer.address обнуляемым, подними city на уровень Customer — и каждое место вызова, которое шло через него, ломается. Вызывающий заплатил за знание, которое ему было не нужно: он хотел город, а купил карту внутренностей трёх объектов.

Скрыть делегата: попроси у ближайшего объекта то, что тебе нужно, и пусть он сам пройдёт остаток цепочки. Лекарство от цепочки сообщений — обычно скрыть делегата: затолкать навигацию за объект, который ты уже держишь, чтобы вызывающий зависел только от своего непосредственного соседа.

class Order {
  constructor(private customer: Customer) {}
  // «единственный друг» вызывающего отдаёт конечную точку напрямую
  get shippingCity(): string {
    return this.customer.address.city; // Order владеет этим проходом, а вызывающий — нет
  }
}

// вызывающий теперь касается одного типа, а не трёх
const city = order.shippingCity;

Это закон Деметры («говори только со своими непосредственными друзьями»), применённый как рефакторинг: вызывающий говорит только с Order. Если Address позже свернётся в Customer, единственное ломающееся место — внутри Order.shippingCity — одна правка, а не сорок. Цепочка не исчезла; она переехала в объект, который законно владеет этой связью.

Посредник — это скрытие делегата, доведённое до перебора: класс, методы которого только переадресуют. Примени скрыть делегата ко всему — и получишь противоположный запах. Если половина методов Order — однострочные переадресации к customer, то Order стал посредником — налогом на проброс. Каждый новый метод на Customer теперь требует своего метода-близнеца, делегирующего на Order, и каждому читателю приходится прыгать через переадресацию, чтобы понять, где работа реально происходит.

class Order {
  constructor(private customer: Customer) {}
  // ничего из этого не делает ничего, кроме переадресации — чистый проброс
  get name() { return this.customer.name; }
  get email() { return this.customer.email; }
  get city() { return this.customer.address.city; }
  get phone() { return this.customer.phone; }
}

Лекарство — удалить посредника: удалить переадресующие методы и дать вызывающим говорить с настоящим объектом — order.customer.email. Обменять цепочку на пустую обёртку — не прогресс; ты добавил класс на сопровождение, который не несёт собственного поведения.

«Говори, не спрашивай» часто растворяет оба запаха разом. Цепочки и посредники нередко появляются потому, что вызывающий спрашивает данные, а затем действует на них где-то ещё — вытаскивает город, чтобы посчитать доставку вдали от данных. Перенеси поведение к данным: скажи объекту выполнить работу.

// СПРОСИ: вызывающий лезет внутрь, берёт данные, решает — цепочка + логика вдали от данных
const city = order.getCustomer().getAddress().getCity();
const fee = isRemote(city) ? 15 : 5;

// СКАЖИ: объект, владеющий данными, отвечает на настоящий вопрос
class Order {
  shippingFee(): number {
    return this.customer.isRemote() ? 15 : 5; // граф остаётся приватным
  }
}
const fee = order.shippingFee();

Теперь ни один вызывающий не ходит по графу и нет обёртки, существующей лишь ради переадресации getCity. Senior-ход — спросить, зачем вызывающему вообще понадобилось это глубокое значение; часто честный ответ — это метод, которому следовало жить на объекте, а не навигация, которую надо прятать.

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

Поэтому правило не «устранить все цепочки» и не «устранить всё делегирование». Часть делегирования — здоровая инкапсуляция: она прячет связь, о которой вызывающему незачем знать. Слишком много — шум: обёртки, которые ничего не прячут, потому что связь и так часть публичной модели (list.length, Promise.then, fluent-билдер — это цепочки, которые надо оставить в покое). Навык в том, чтобы читать, что есть что: прячет ли это делегирование что-то, что вероятно изменится, или просто ретранслирует то, что уже публично?