GRASP (от — шаблоны ПО для назначения главных ответственностей; также отсылает к — «способность быстрого восприятия, понимание, схватывание») — шаблоны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.
В книге Крэга Лармана «Применение UML и шаблонов проектирования»Larman, Craig. Applying UML and Patterns — Third Edition. описано 9 таких шаблонов: каждый помогает решить некоторую проблему, возникающую как в объектно-ориентированном анализе, так и в практически любом проекте по разработке программного обеспечения. Таким образом, шаблоны «GRASP» — хорошо документированные, стандартизированные и проверенные временем принципы объектно-ориентированного анализа, а не попытка привнести что-то принципиально новое.
Каталог шаблонов Краткая характеристика девяти шаблонов:
1. Информационный эксперт (Information Expert) Шаблон определяет базовый принцип распределения ответственностей. Обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом.
Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится спагетти-код, в котором трудно разобраться.
Локализация же ответственностей, проводимая согласно шаблону: Повышает: Инкапсуляцию; Простоту восприятия; Готовность компонентов к повторному использованию; Снижает: степень зацепления.
2. Создатель (Creator) Проблема: Кто отвечает за создание объекта некоторого класса A?
Решение: Назначить классу B обязанность создавать объекты класса A, если класс B: содержит(contains) или агрегирует(aggregate) объекты A; записывает(records) объекты A; активно использует объекты A; обладает данными для инициализации объектов A
Можно сказать, что шаблон «Creator» — это интерпретация шаблона «Information Expert» (смотрите пункт № 1) в контексте создания объектов.
Большинство порождающих шаблонов проектирования так или иначе выводятся или опираются на шаблон «Creator».
3. Контроллер (Controller) Отвечает за операции, запросы которых приходят от пользователя, и может выполнять сценарии одного или нескольких вариантов использования (например, создание и удаление); Не выполняет работу самостоятельно, а делегирует компетентным исполнителям; Может представлять собой: Систему в целом; Подсистему; Корневой объект; Устройство.
4. Слабое (низкое) зацепление (Low Coupling)
Зацепление — мера того, насколько взаимозависимы разные подпрограммы или модули.
Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы.
5. Сильная (высокая) связность (High Cohesion)
Связность — мера силы взаимосвязанности элементов внутри модуля; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом.
Сильная связность класса / модуля означает, что его элементы тесно связаны и сфокусированы.
Слабая (низкая) связность класса / модуля означает, что он не сфокусирован на одной цели, его элементы предназначены для слишком многих несвязанных обязанностей. Такой модуль трудно понять, использовать и поддерживать.
6. Полиморфизм (Polymorphism)
Устройство и поведение системы: Определяется данными; Задано полиморфными операциями её интерфейса. Пример: Адаптация коммерческой системы к многообразию систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «Адаптеры»).
7. Чистая выдумка (Pure Fabrication) Не относится к предметной области, но: Уменьшает зацепление; Повышает связность; Упрощает повторное использование. «Pure Fabrication» отражает концепцию сервисов в модели предметно-ориентированного проектирования.
Пример задачи: Не используя средства класса «А», внести его объекты в базу данных.
Решение: Создать класс «Б» для записи объектов класса «А» (см. также: «Data Access Object»).
8. Перенаправление (Indirection)
Слабое зацепление между элементами системы (и возможность повторного использования) обеспечивается назначением промежуточного объекта их посредником.
Пример: В архитектуре Model-View-Controller, контроллер (англ. controller) ослабляет зацепление данных (англ. model) с их представлением (англ. view).
9. Устойчивость к изменениям (Protected Variations) Шаблон защищает элементы от изменения другими элементами (объектами или подсистемами) с помощью вынесения взаимодействия в фиксированный интерфейс, через который (и только через который) возможно взаимодействие между элементами. Поведение может варьироваться лишь через создание другой реализации интерфейса.
См. также Паттерны проектирования
Примечания
Категория:Объектно-ориентированное программирование Категория:Шаблоны проектирования Категория:Проектирование программного обеспечения