Как на собеседовании определить, что класс нарушает Single Responsibility Principle: по числу методов и разным DTO?

Как выявить нарушение Single Responsibility Principle

• принцип SRP означает, что класс должен иметь одну ответственность/причину для изменения
• о нарушении говорит ситуация, когда класс реализует несколько разных функций или задач
• одним из признаков может быть множество методов, связанных с различными аспектами логики
• ещё один сигнал — возврат разных DTO (объектов передачи данных), описывающих неодинаковую бизнес-логику
• к нарушениям также приводят сложности сопровождения, тестирования и внесения изменений в код
• если класс меняется по разным причинам, это обычно указывает на высокую связность и низкую когезию
• декомпозиция классов повышает читаемость, повторное использование и декомпозицию

Итог: SRP нарушен, если класс объединяет разные бизнес-контексты или сущности. Это можно заметить по методам с разной семантикой и неодинаковым DTO.

Подробный ответ

Основной ответ

Single Responsibility Principle (SRP) требует, чтобы у класса была только одна причина для изменения — одна определённая задача или зона ответственности. Нарушение SRP возникает, когда класс объединяет несколько логически независимых функций: обработку данных, бизнес-логику, валидацию, взаимодействие с UI или сохранение информации в базе данных. Проверять соблюдение SRP следует не только по числу методов. Важно оценить их смысл, а также типы входных и выходных данных. Если методы используют разные сущности (DTO), решают несвязанные задачи и должны изменяться по разным причинам, это явный признак того, что класс отвечает сразу за несколько областей.

Ключевые моменты

• Разные причинные факторы изменений: если один класс приходится менять из-за бизнес-правил, формата вывода и механизма сохранения данных, он, скорее всего, объединяет несколько обязанностей.
• Разнообразие DTO: если методы принимают и возвращают несколько независимых DTO, это может свидетельствовать о наличии разных сфер ответственности, которые целесообразно разделить.
• Большое количество методов с разной семантикой: само по себе число методов не доказывает нарушение SRP. Однако если они обслуживают разные бизнес-задачи — например, одновременно выполняют расчёты и формируют отчёты, — единая ответственность отсутствует.
• Переход на разделение: для разграничения функций и снижения связности обычно выделяют отдельные сервисы, репозитории, фасады и трансформеры.

Практический контекст

В прикладных проектах, например на Java с Spring или C# с .NET, нарушение SRP усложняет сопровождение: изменение одной части класса может вызвать побочные эффекты в другой. Для исправления часто создают отдельные сервисы и мапперы DTO, а также используют подходы Clean Architecture и Domain-Driven Design, при которых класс сосредоточен на одной абстракции. При анализе кода применяют метрики, в частности LCOM (Lack of Cohesion of Methods), позволяющие количественно оценить связанность методов внутри класса и определить кандидатов на рефакторинг.