Чек-лист: не нарушаете ли вы SRP?

Этот раздел нужен только для проведения проверок, если вы уже понимаете SRP или совсем его не понимаете.

Если вы можете самостоятельно провести анализ кода и зарефакторить его — делайте, только потом переходите к чек-листу.

Желательно попросить кого-нибудь задать наводящие вопросы, по типу:

“А это точно должно быть здесь?”

“А можно ли это убрать?”

“А что будет, если это изменить?”

Только так вы наилучшим способ усвоите информацию.

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

Можно ли описать, что делает класс, одним предложением без союзов «и», «а также», «к тому же»?
- Пример: «Управляет пользователями» — хорошо. «Управляет пользователями и отправляет письма» — плохо.
Если изменится формат хранения данных (например, перейдёте с MySQL на PostgreSQL), затронет ли это этот класс?
- Если да — он слишком много знает о деталях хранения.
Если изменится способ логирования (с файлов на базу данных), придётся ли править этот класс?
- Если да — логирование не его ответственность.
Если изменится бизнес-правило для одного из методов, сломаются ли другие методы класса?
- Например, если вы правите sendWelcomeEmail, должен ли остаться рабочим updateUser? Если нет — класс связан слишком сильно.
Может ли этот класс понадобиться другой команде/отделу для своих целей?
- Если да, то у него может быть несколько акторов (причин для изменения). Это признак нарушения SRP.
При тестировании класса вам приходится мокать больше двух внешних зависимостей?
- Это косвенный признак того, что класс делает слишком много — у него слишком много «почему».
Вы добавляете новый функционал в этот класс чаще, чем раз в месяц?
- Частые изменения — сигнал, что класс собирает в себе слишком много ответственности.

Если вы ответили «да» на 3 и более вопросов — выделите отдельные зоны ответственности в новые классы. Если «да» на 1–2 — можно оставить как есть, но помните о рисках.