Что такое принцип единственной ответственности (SRP): пример нарушения?

Принцип единственной ответственности: у класса должна быть одна причина для изменения — одна ось изменения требований, а не «один метод на класс».

Пример нарушения

class Report {
  calculate() { /* бизнес-правила */ }
  toHtml() { /* представление */ }
  saveToDb() { /* персистентность */ }
}

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

Исправление

• ReportCalculator — логика расчёта.
• ReportFormatter — рендеринг.
• ReportRepository — сохранение.

Как измерять ответственность

Спросите «кто запрашивает изменения?»: если актёров несколько — аналитик, дизайнер, администратор БД — то и ответственностей несколько.

Типичная ошибка

Дробить всё подряд до классов на одну строку — тоже запах: SRP про согласованность изменений, а не про размер.

Коротко для собеседования

SRP требует, чтобы у модуля был один источник изменений — один актёр или ось требований. Класс, где смешаны расчёт, вёрстка и сохранение, делят на части; обратная ошибка — дробить код до микроклассов, ведь принцип про причины изменений, а не про размер.