tgoop.com/javaproglib/6775
Create:
Last Update:
Last Update:
О принципе единственной ответственности слышали все. Конечно правильный ответ согласно книги Роберта Мартина "Чистая архитектура": SRP - это принцип единой ответственности.
Но при попытке разобраться в более дательном понимании принципа его часто трактуют слишком буквально:
Метод должен реализовывать одну задачу
Класс должен отвечать за один функционал
Да, это отчасти верно и такой принцип тоже есть, но он применяется на низшем уровне системы. SRP же применяется на более высоком уровне.
В итоге получаются сервисы, в которых вроде как всё «по SRP», но изменения в одном бизнес-сценарии ведут к каскадным правкам в десятках файлов. Это сигнал: принцип нарушен, несмотря на формальное соблюдение.
🔹 О чём на самом деле говорит SRP
В классическом изложении (по Роберту Мартину):
Модуль должен иметь только одну причину для изменения.
И под модулем понимается не метод и не даже один класс, а группа классов и интерфейсов, объединённая общим потребителем — актором.
🔹 Что это означает на практике
1. Определите акторов
Актор — это не всегда пользователь. Это может быть внешний сервис, внутренний инструмент, регламент. Важно: требования акторов не должны пересекаться. Если они меняются независимо — значит, им нужны отдельные модули.
2. Постройте модули вокруг акторов
Частая ошибка — «модуль пользователей», в котором и логика регистрации, и рассылка писем, и обработка GDPR-запросов.
Лучше разделить:
▪️ один модуль обслуживает end-user’а,
▪️ другой — юридические требования,
▪️ третий — внутреннюю админку.
3. Не дробите код ради SRP, если это нарушает целостность модуля
SRP — это не о размере, а о мотивации изменений. Метод в 100 строк, обслуживающий один сценарий, допустим. А вот класс, который реагирует на десяток независимых событий — нет.
🔹 Пример
public class OrderService {
public void placeOrder() { ... }
public void notifyCustomer() { ... }
public void saveAuditLog() { ... }
}Этот класс изменится при любом изменении в бизнес-логике, в уведомлениях или в логировании. Три причины изменения — три актора.
▪️ OrderProcessor — отвечает за бизнес-сценарий
▪️ NotificationService — отправка сообщений
▪️ AuditService — логирование
Каждый компонент обслуживает одного актора, имеет свою причину для изменений и независимую эволюцию.
🔹 Вывод
SRP стоит понимать как инструмент для проектирования архитектуры. Его задача — отделить контексты, которые меняются по разным причинам, и тем самым минимизировать связность и ограничить зону изменений. Не методы, не классы, а контексты и акторы.