Что такое принцип единственной ответственности (Single Responsibility Principle)

Что проверяют

Понимаете ли вы, что SRP говорит не про «один метод на класс», а про одну причину для изменения. На Android разговор почти всегда переходит к толстой Activity, и следом просят показать, где в вашем проекте проходит граница между ViewModel, репозиторием и use case.

Как отвечать

Начните с формулировки Роберта Мартина: у модуля должна быть одна причина для изменения. Позже он уточнил, что причина это конкретная группа людей (актор), чьи требования меняют код. Бухгалтерия и служба безопасности не должны править один и тот же класс.

Дальше покажите на Android:

• нарушение: Activity, которая сама ходит в сеть через Retrofit, парсит ответ, пишет в Room и форматирует даты для экрана. Смена API, схемы базы или дизайна трогает один файл;
• ViewModel: держит состояние экрана и переживает смену конфигурации, но не знает, откуда пришли данные;
• репозиторий: решает, брать данные из сети или из кэша, и прячет Retrofit и Room за интерфейсом;
• use case (интерактор): одна бизнес-операция, например «оформить заказ», которую можно переиспользовать в нескольких ViewModel;
• адаптер RecyclerView: только связывает данные с разметкой, а форматирование и реакцию на клики отдаёт наружу.

Назовите практическую выгоду. Класс с одной ответственностью проще тестировать: для юнит-теста ViewModel достаточно подменить репозиторий фейком, без эмулятора и Robolectric. Изменения локализуются, а конфликтов при слиянии в команде становится меньше.

Где спотыкаются

Трактуют SRP как «класс должен делать одну вещь» и дробят код до классов в пять строк. Получается десяток Helper и Manager, связи между которыми сложнее исходной проблемы.

Приводят только учебный пример с User и EmailService и не могут показать нарушение в собственном Android-коде. Интервьюер почти всегда просит пример из проекта.

Путают SRP с разделением на слои. Слой data тоже может нарушать принцип, если один репозиторий обслуживает сразу профиль, платежи и настройки уведомлений.