Одна причина для изменения

SRP — про одну причину для изменения, а не про одно сделанное дело. Собственная поправка Роберта Мартина пряма: принцип никогда не был «модуль должен делать одно дело». Эта народная версия — то, что помнит большинство, и именно поэтому про SRP спорят бесконечно — у вопроса «считаются ли парсинг и валидация за одно дело или за два?» нет ответа. Реальная формулировка: у модуля должна быть одна, и только одна, причина для изменения. «Причина для изменения» — это не фича и не метод; это источник требований — человек или роль, которые могут прийти и потребовать, чтобы поведение было другим.

// "Does this do one thing?" — unanswerable, and the wrong question.
// "Who can ask me to change this?" — answerable, and the right one.

Сдвиг от подсчёта глаголов к определению заказчиков — это весь урок целиком.

«Причина для изменения» — это актор. Мартин заостряет «причину для изменения» в актора: группу пользователей или стейкхолдеров, ради которых делается данное изменение. Финансы определяют, как считается оплата. HR определяет, что считается отчётными часами. Команда DBA определяет схему хранения. Каждый — отдельный актор с отдельными требованиями, которые дрейфуют по собственному расписанию. Каноническое нарушение — один класс, обслуживающий всех трёх:

class Employee {
  calculatePay(): Money { /* Finance owns this rule */ }
  reportHours(): Hours { /* HR owns this rule */ }
  save(): void      { /* DBA owns this schema */ }
}

Три актора. Три причины для изменения. SRP говорит: модуль, отвечающий перед тремя акторами, — это три обязанности под одним именем.

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

class Employee {
  // Both pay and the HR report call this. Finance "owns" it conceptually.
  private regularHours(): Hours { /* shared helper */ }

  calculatePay(): Money { return rate.times(this.regularHours()); }  // Finance
  reportHours(): Hours  { return this.regularHours(); }              // HR reads the SAME helper
}

Финансы просят изменить, как regularHours() округляет, по расчётным причинам. Ты вносишь правку. Отчёт HR — у которого не было причин меняться — теперь показывает другие числа. Этого никто не просил. Вот катастрофа, от которой страхует SRP: требование Финансов дотягивается и ломает фичу HR, потому что они были сварены вместе. Связанность невидима, пока не выкатит неверный отчёт.

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

class EmployeeData { /* just the fields; no business rules */ }

class PayCalculator   { calculatePay(e: EmployeeData): Money { /* Finance only */ } }
class HoursReporter   { reportHours(e: EmployeeData): Hours  { /* HR only */ } }
class EmployeeRepository { save(e: EmployeeData): void { /* DBA only */ } }

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