Дробить, не раскалывая

SRP — про причины для изменения, а не про размер. Принцип часто неверно цитируют как «класс должен делать одну вещь», что подталкивает считать операторы и дробить, пока у каждого класса не останется один метод. Настоящая формулировка точнее: у модуля должна быть одна причина для изменения — или, что то же самое, он должен отвечать перед одним актором. «Актор» — это источник изменения: заинтересованная сторона, политика, протокол, который эволюционирует по своим часам.

// Классический пример Роберта Мартина: три актора прячутся в одном классе.
class Employee {
  calculatePay()  { /* меняется, когда меняется CFO / политика расчёта зарплаты */ }
  reportHours()   { /* меняется, когда меняется COO / операционная отчётность */ }
  save()          { /* меняется, когда меняется DBA / схема БД */ }
}

Эти три метода обслуживают трёх разных акторов, которые меняются по несвязанным причинам. Именно это — а не число строк — причина, почему Employee следует разделить. Правильное число частей — это число независимых причин для изменения, не больше и не меньше. Размер — это симптом, который ты исследуешь; он не само правило.

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

// Разные часы → дробим. PricingPolicy меняется по ритму финансов;
// ReceiptTemplate меняется по ритму маркетинга. Они никогда не движутся вместе.
class PricingPolicy   { totalFor(cart: Cart): Money { /* этим владеют финансы */ } }
class ReceiptTemplate { render(order: Order): Html  { /* этим владеет маркетинг */ } }

Тест эмпирический: посмотри историю git. Если две области файла появляются в коммитах по разным причинам — это реальный шов. Дробление вдоль него означает, что будущие изменения останутся локальными: правка финансов трогает только PricingPolicy. Дробление поперёк него (по часам, которые ты выдумал) ничего не даёт и стоит косвенности.

Держи вместе то, что всегда меняется вместе и делит состояние. Обратный тест не менее важен и куда чаще игнорируется. Два куска логики, которые всегда попадают в один коммит, разделяют одни инварианты, читают и пишут одни и те же поля, — это одна обязанность под двумя именами методов. Разделить их — значит разбросать единый концепт по файлам и заставить каждое изменение прыгать между ними.

// Связно: и validate, и apply обеспечивают ОДИН инвариант
// (баланс никогда не уходит в минус) над ОДНИМ полем. Они всегда
// меняются вместе. Разбить их на классы Validator + Applier означало бы,
// что инвариант живёт в двух файлах, которые надо держать в синхроне.
class Account {
  #balance: Money;
  withdraw(amount: Money): void {
    if (amount.gt(this.#balance)) throw new InsufficientFunds();
    this.#balance = this.#balance.minus(amount); // то же поле, то же правило
  }
}

Когда ты дробишь это, изменение правила овердрафта теперь означает правку AccountValidator и AccountApplier и удержание их согласованными — ты изготовил ту самую дробовую хирургию, которой пытался избежать. Конкассентная логика (то, что должно меняться вместе, чтобы оставаться корректным) принадлежит вместе. Высокая связность и есть цель; SRP — лишь один рычаг на неё.

Взрыв числа классов — это провал SRP, а не успех SRP. Когда дробление порождает классы, у которых нет независимой причины для изменения, — Validator и Applier, которые всегда правятся в одном PR, Mapper, существующий лишь чтобы перенести три поля, — ты понизил связность, а не повысил. Цена реальна, и платят её при каждом чтении: косвенность без информации. Чтобы ответить на «что делает оформление заказа?», ты теперь открываешь восемь файлов и держишь их взаимодействие в рабочей памяти, потому что поведение раскололи между ними без границы, которая хоть что-то значит.

// Переприменённый SRP: одна связная операция атомизирована в делегирующие оболочки.
class OrderValidator    { validate(o: Order) { /* один if */ } }
class OrderPriceApplier { apply(o: Order)    { /* одна строка, зовёт Calculator */ } }
class OrderTotaller     { total(o: Order)    { /* одна сумма */ } }
// placeOrder() теперь оркеструет семь таких. Чтение его — это пересборка.

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