Что такое принцип единственной ответственности?

Принцип единственной ответственности (Single Responsibility Principle, SRP) — первый из пяти принципов SOLID. Его классическая формулировка: «У класса должна быть только одна причина для изменения». Это значит, что модуль, класс или функция должны отвечать за одну конкретную часть функциональности системы.

Что считается «ответственностью»

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

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

class Report {
  constructor(data) { this.data = data; }

  generate() {
    // формирование отчёта
    return `Report: ${JSON.stringify(this.data)}`;
  }

  saveToFile(path) {
    // запись в файл
    require('fs').writeFileSync(path, this.generate());
  }

  sendEmail(email) {
    // отправка по почте
    console.log(`Send to ${email}: ${this.generate()}`);
  }
}

Здесь класс знает и про формат отчёта, и про файловую систему, и про почту. Изменение любого из этих аспектов затрагивает Report.

Как применить SRP

Разделим обязанности на отдельные классы, каждый из которых меняется по своей причине:

class Report {
  constructor(data) { this.data = data; }
  generate() { return `Report: ${JSON.stringify(this.data)}`; }
}

class ReportSaver {
  save(report, path) {
    require('fs').writeFileSync(path, report.generate());
  }
}

class ReportMailer {
  send(report, email) {
    console.log(`Send to ${email}: ${report.generate()}`);
  }
}

Теперь Report отвечает только за формирование, ReportSaver — за сохранение, ReportMailer — за отправку. Каждый класс имеет одну причину для изменения.

Где это применяется

• Проектирование классов и модулей в ООП и функциональном коде.
• Разделение слоёв в архитектуре: контроллер, сервис, репозиторий.
• Рефакторинг «божественных объектов», которые знают слишком много.
• Написание unit-тестов: чем меньше ответственность, тем проще тестировать.

Важно не путать SRP с принципом «одна функция — одно действие». Речь именно о причинах изменения с точки зрения бизнеса или инфраструктуры. Иногда класс с несколькими методами всё равно соответствует SRP, если все методы служат одной цели.

Итог: применяйте SRP, когда класс или модуль меняется по нескольким независимым причинам — разделение повышает читаемость, тестируемость и снижает связанность кода.