GRASP¶

GRASP — это набор принципов, которые помогают распределять ответственность между объектами и модулями.

В отличие от GOF, это не каталог готовых шаблонов, а набор вопросов: кто должен знать, кто должен создавать, кто должен координировать и как не связать систему в узел.

Принципы GRASP¶

Принцип	Описание	На что смотреть
Информационный эксперт (`Information Expert`)	Ответственность получает тот, у кого уже есть нужные данные для ее выполнения.	Не тянуть логику в случайный общий модуль, если нужный контекст уже рядом.
Создатель (`Creator`)	Объект создает тот, кто тесно связан с создаваемым объектом или владеет его данными.	Кто агрегирует, хранит или инициализирует создаваемую сущность.
Контроллер (`Controller`)	Внешние запросы принимает объект-координатор сценария, а не низкоуровневые участники.	Кто управляет use case целиком и не смешивает orchestration с деталями.
Низкая связанность (`Low Coupling`)	Зависимостей между частями системы должно быть как можно меньше.	Насколько дорого менять один модуль из-за устройства другого.
Высокая связность (`High Cohesion`)	Каждый модуль должен иметь узкую и понятную зону ответственности.	Не превращается ли модуль в склад разнородной логики.
Полиморфизм (`Polymorphism`)	Поведение по вариантам лучше раскладывать по реализациям, а не по длинным веткам условий.	Можно ли заменить `Если ... ИначеЕсли ...` на общий контракт и набор реализаций.
Чистая выдумка (`Pure Fabrication`)	Иногда стоит ввести отдельный служебный объект, если это уменьшает связанность и упрощает модель.	Где вспомогательный сервис полезнее, чем перегрузка доменных объектов чужой логикой.
Посредничество (`Indirection`)	Между подсистемами вводят промежуточный слой, чтобы ослабить прямую зависимость.	Нужен ли адаптер, фасад, шина или сервис-обертка для развязки модулей.
Защищенные вариации (`Protected Variations`)	Точки возможных изменений закрывают стабильным интерфейсом.	Где стоит отделить контракт от реализации, чтобы изменения не разносились по всей системе.